WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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

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