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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

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

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

Jan

> 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