Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of IS_PRIV_FOR() and rcu_[un]lock_domain().

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 5/4/08 15:28, "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx> wrote:

>> They were all fine, except there was one inexplicable check of IS_PRIV_FOR()
>> in bind_interdomain() which I nuked. It was so bizarre that I assumed you
>> must have put it there for a reason, and this would be one that you'd
>> complain about.
> 
> I'm now complaining :)
> 
> The bind_interdomain() trick is needed for the ioreq events channel:
> when it gets installed, it is supposed to be between the HVM domain and
> dom0 (the stub domain doesn't exist anyway).  The meaning of the test is
> hence to allow the stub domain to hijack that event channel (because it
> has privileges on the remote domain).

The hack kind of sucks. :-) Add a new hvm_param to indicate the device model
domain. Default it to zero, and if it becomes set to some other value (by
the stub domain itself, when it starts) then re-create the event-channel
port with new remote domid.

 -- Keir

> With that fix, stub domains are working again (but Cirrus bios doesn't
> work yet)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel