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:55 +0100, Jan Beulich wrote:
> >>> On 21.07.11 at 10:38, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Thu, 2011-07-21 at 09:16 +0100, Jan Beulich wrote:
> >> > 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
> You still didn't tell where such a message would show up: Printing
> such a message isn't a big deal, but pointless if it goes into no-where.
> If instead the hypervisor (for Dom0) or the tools (for DomU-s) print
> something, this will be visible in a known place.

If someone runs a dom0-only kernel as a domU (presumably by mistake)
then they are naturally going to look in the domU console ring for error
messages when it doesn't work (because they thought they were running a
domU, where else would they look?). Placing that message there is
basically a memcpy and an evtchn_notify.

If someone runs a domU only kernel as a dom0 then the XENFEAT_privileged
(or whatever it gets called) is precisely enough to allow the hypervisor
to say something useful in that case.


Xen-devel mailing list

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