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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 21.07.11 at 10:55, Keir Fraser <keir@xxxxxxx> wrote:
> On 21/07/2011 09:50, "Keir Fraser" <keir@xxxxxxx> wrote:
> 
>> On 21/07/2011 09:16, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> 
>>>> You say it is a Linux notion that dom0 implies domU but I am not aware
>>>> of any PV OS which supports dom0 that doesn't also support domU, do you
>>>> have specific examples of OSes which are dom0-only?
>>> 
>>> No, I'm not aware of any existing ones, but I also wasn't in favor of
>>> the move to imply unprivileged capabilities when Linux is configured
>>> as privileged guest (iirc this wasn't the case from the very beginning).
>>> 
>>> And again, imo an interface like the hypervisor's shouldn't dictate any
>>> kind of policy on the guest OSes.
>> 
>> 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?
> 
> A further killing blow: the hypervisor patch defined unprivileged as !dom0.
> Well, there are many different capabilities and devices that a domU may be
> granted. You might be passing through a VGA adaptor and SRIOV NIC and run
> out of ramdisk for example, in which case the domU might quite validly have
> no PV frontend devices.
> 
> Another thing, given that privileged is quite a broad term, I wonder whether
> the 'privileged' feature should be called something else? Like
> 'dom0_interface'? It would be a more precise definition maybe? Passing
> through devices to a domU could be termed a privilege after all, for
> example.

I agree that if we're going to go with just a single flag, then renaming it
the way you suggest certainly makes sense.

Jan


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