[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.