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] add privileged/unprivileged kernel feature indic

To: "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] add privileged/unprivileged kernel feature indication
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 05 Jul 2011 15:15:19 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 05 Jul 2011 07:15:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1309874159.634.130.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E132450020000780004C297@xxxxxxxxxxxxxxxxxxxx> <1309874159.634.130.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 05.07.11 at 15:55, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2011-07-05 at 13:48 +0100, Jan Beulich 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.
> While I agree that this is a useful change I think you should also try
> and ensure that your bootloader configuration tool tries not to add
> invalid combinations to the configuration. For example grub2's
> "update-grub" command checks for CONFIG_XEN_PRIVILEGED_GUEST=y before
> creating a dom0 style entry. IIRC grub1 did the same (although that may
> have been Debian specific).

That I would consider completely bogus - the boot loader should not
have a need to know *anything* about the kind of kernel it boots.


Xen-devel mailing list