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: "Ian Campbell" <Ian.Campbell@xxxxxxxxxxxxx>, "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH, v2] add privileged/unprivileged kernel feature indication
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 21 Jul 2011 10:54:12 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jul 2011 02:54:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA4DB11E.2FA04%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>
References: <CA4DAB86.2F9EC%keir@xxxxxxx> <CA4DB11E.2FA04%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 21.07.11 at 11:34, Keir Fraser <keir@xxxxxxx> wrote:
> 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,

Since there doesn't seem to be any use of the "required" marker so far,
I didn't want to introduce these. But we certainly could (though for the
moment I'm preparing an updated patch with just the _SUPPORTED_

> XENFEAT_dom0_interface or somesuch, and:
> Dom0 only: required_features |= dom0_interface
> Dom0/DomU: supported_features |= dom0_interface
> DomU only: n/a

Yes, that's what I basically did now.


> 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
> XEN_ELFNOTE_REQUIRED_FEATURES, and turn that into a
> guest_has_modern_feature_flags boolean which you can integrate into various
> acceptance checks).
>  -- Keir
>>  -- Keir

Xen-devel mailing list