This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of IS_PRIV_FOR() and rcu_[un]lock_domain().
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 05 Apr 2008 17:31:39 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 05 Apr 2008 09:32:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080405142814.GL4005@implementation>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciXOoXfxC1FAAMtEd2FkwAWy6hiGQ==
Thread-topic: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of IS_PRIV_FOR() and rcu_[un]lock_domain().
User-agent: Microsoft-Entourage/
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