WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH, v2] add privileged/unprivileged kernel feature i

To: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH, v2] add privileged/unprivileged kernel feature indication
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 21 Jul 2011 10:47:03 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 21 Jul 2011 02:47:52 -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>
Organization: Citrix Systems, Inc.
References: <CA4DB11E.2FA04%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-07-21 at 10:34 +0100, Keir Fraser 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,
> 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
> XEN_ELFNOTE_REQUIRED_FEATURES, and turn that into a
> guest_has_modern_feature_flags boolean which you can integrate into various
> acceptance checks).

That sounds reasonable to me.

Ian.



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