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] [PATCH, v2] add privileged/unprivileged kernel feature i

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, v2] add privileged/unprivileged kernel feature indication
From: Keir Fraser <keir@xxxxxxx>
Date: Thu, 21 Jul 2011 10:34:06 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jul 2011 02:34:59 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=lli/D5GqqYbp8Ipef+J1SuozqOlNSBhrMtv8E9iaxzY=; b=h8EWcEROmaXPquFDid3tzPMU/xalLxO9emO7VjTArv366n/pWDZQFyfda1y3yX+EAZ OUV0ns+iDo0NRdEhZDWVj0Qt72zVGSC4mbC0kVKqXS5EpuO+wy+zkMEgns/Uzl7VQatW bu5uMGwE/7LeaXwQ9UIEYLquVzqJioPaNa1Fc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA4DAB86.2F9EC%keir@xxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxHhgAdiEmYK34J0EuWWhBkeGNYWQAA1WLz
Thread-topic: [Xen-devel] [PATCH, v2] add privileged/unprivileged kernel feature indication
User-agent: Microsoft-Entourage/
On 21/07/2011 10:10, "Keir Fraser" <keir@xxxxxxx> wrote:

> On 21/07/2011 10:01, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>> My own issue with the unprivileged flag is that I'm not clear what it
>>> actually means. When would you *not* set it? I mean it looks in the Linux
>>> side you set it unconditionally right now. What's the point? Why not remove
>>> the flag and introduce it when we have good reason and can attach meaningful
>>> semantics to it?
>> Again - you're talking about an actual guest side implementation (which,
>> in this particular case, has to honor how the rest of the implementation
>> is done, i.e. it has to set the flag unconditionally). I'm talking about an
>> abstract interface definition that should suit everyone (existing as well
>> as yet to come).
> I'm afraid my view is that !dom0 operation is a mode that every PV guest is
> capable of -- that's the definition of what a PV guest is, to my mind!
> Like I said in my other email, pinning it down more precisely -- e.g., must
> have PV drivers -- will have counterexamples.
> I don't know though --- maybe a distro could have dom0 and domU separate
> kernel builds, and want to set the flags differently for each. I wonder how
> much of a long shot that use case is.

How about having a XEN_ELFNOTE_REQUIRED_FEATURES as well as
supported_features? Then you can define just one flag,
XENFEAT_dom0_interface or somesuch, and:
Dom0 only: required_features |= dom0_interface
Dom0/DomU: supported_features |= dom0_interface
DomU only: n/a

In the hypervisor/tools, gate the acceptance check on new enough kernel
(i.e., based on whether the kernel has XEN_ELFNOTE_SUPPORTED_FEATURES and/or
guest_has_modern_feature_flags boolean which you can integrate into various
acceptance checks).

 -- Keir

>  -- Keir

Xen-devel mailing list