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

[Keir Fraser <keir@xxxxxxx>]

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).

 -- Keir

>  -- Keir
> 
> 



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