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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2011-07-21 at 09:16 +0100, Jan Beulich wrote:
> >>> 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).

Your Linux side patch sets the unprivileged guest feature independently
of CONFIG_XEN_FRAMEBUFFER and/or CONFIG_HVC_XEN so the proposed
interface is already providing opportunities for confusion/ambiguity.

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

We are talking about half a dozen lines of code to spit out a static
string ("I don't support domU operation") to the domU and/or a guest
side decision to omit sch code on the understanding that the
disadvantage will be less error reporting when a minimal kernel suiting
a particular need is used in some other context.

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

The only policy here is "if you want to be user friendly you must
minimally arrange to output a simple domU console message indicating
lack of domU support if you support dom0 operation only".

That's not so much a policy as pushing responsibility down into the
guest kernel in an extremely unlikely configuration.

Ian.


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