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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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