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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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?

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.

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?

Ian.




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