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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 21.07.11 at 10:01, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Wed, 2011-07-20 at 13:50 +0100, Jan Beulich wrote: 
>> >>> On 20.07.11 at 12:39, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>> > On Tue, 2011-07-19 at 14:17 +0100, Jan Beulich wrote:
>> >> Oops, $subject should have said [PATCH, v3] ...
>> >> 
>> >> >>> On 19.07.11 at 15:16, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> >> > With our switching away from supporting 32-bit Dom0 operation, users
>> >> > complained that attempts (perhaps due to lack of knowledge of that
>> >> > change) to boot the no longer privileged kernel in Dom0 resulted in
>> >> > apparently silent failure. To make the mismatch explicit and visible,
>> >> > add feature flags that the kernel can set to indicate operation in
>> >> > what modes it supports. For backward compatibility, absence of both
>> >> > feature flags is taken to indicate a kernel that may be capable of
>> >> > operating in both modes.
>> > 
>> > Actually, since you are introducing a new interface to the feature bits
>> > _and_ it is not possible to add these new bits to the old interface
>> > anyway can't we just have XENFEAT_privileged and require that guest
>> > kernels using the new interface ensure that bit correctly represents the
>> > configuration? IOW backwards compatilibilty is ensure through the
>> > presence/absence of XEN_ELFNOTE_SUPPORTED_FEATURES.
>> 
>> At the risk of repeating myself - the notion of "privileged" implying
>> ability to run unprivileged is a Linux one, and I don't want to embed
>> such an implication in the interface.
> 
> At the risk of repeating myself -- which functionality does domU require
> which is not also already necessary for a dom0 -- at least to the point
> of failing gracefully during boot?

Graceful failure requires access to some user visible output device. A
Dom0-only kernel may e.g. not have any frontend drivers (particularly
no xenfb one, and the guest and/or kernel config may not allow other
virtualized output mechanisms).

> You also have not explained _why_ a dom0-only guest would be a useful
> thing to have and to add extra complexity to our interfaces for, it's
> obviously very much a corner case.

It's really a decision between having efficient code (i.e. as little
unused code as possible in a kernel suiting a particular need) and
having a (relatively) general-purpose kernel.

> If we choose to do so we can decree that a dom0-only capable guest must
> also have sufficient domU functionality to print a message when running
> as domU and if they choose not to do this then it only impacts that
> guest and its users (which IMHO provides sufficient pressure on guest
> implementers to do the right thing).
> 
> 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.

Jan


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