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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

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

Jan


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