This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>