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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 19.07.11 at 12:44, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Tue, 2011-07-19 at 11:24 +0100, Jan Beulich wrote:
>> >>> On 19.07.11 at 11:28, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Tue, 2011-07-19 at 10:00 +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.
>> >> 
>> >> v2: Due to the way elf_xen_parse_features() worked up to now (getting
>> >> fixed here), adding features indications to the old, string based ELF
>> >> note would make the respective kernel unusable on older hypervisors.
>> > 
>> > What was the failure mode? Can we not fix it (with suitable backport
>> > recommendations) rather than adding a new duplicated interface?
>> 
>> Adding a supported feature Xen doesn't understand leads to a
>> "cannot load Dom0 kernel" without any indication what was actually
>> wrong with the kernel.
>> 
>> The fix is trivial (this patch's change to elf_xen_parse_features()),
>> but expecting everyone to backport this to (perhaps very) old
>> hypervisors didn't seem realistic to me.
> 
> Backporting a trivial fix like this is pretty easy, especially to this
> code which has been reasonably static for a long time.
> 
> People who need this fix are either building a modern kernel themselves
> (in which case I expect they can cope with getting a fixed hypervisor
> too) or they are getting it from their distro and then the packages
> dependencies will cause the necessary hypervisor fix to get pulled in.

Not really. Just consider virtualization hosters who run on a very old
hypervisor, but offer people to use modern kernels. You just can't
imply that a modern kernel will only run on half-way modern
hypervisors, or that if you have control over the (DomU) kernel, you
also have control over the hypervisor.


>> >>  /* x86: pirq can be used by HVM guests */
>> >> -#define XENFEAT_hvm_pirqs           10
>> >> +#define XENFEAT_hvm_pirqs                 10
>> >> +
>> >> +/* privileged operation is supported */
>> >> +#define XENFEAT_privileged                11
>> >> +
>> >> +/* un-privileged operation is supported */
>> >> +#define XENFEAT_unprivileged              12
>> > 
>> > This still strikes me as odd because unprivileged is a subset of
>> > privileged (I understand the backwards compatibility argument for having
>> > it this way though). Really XENFEAT_unprivileged is the
>> > "XENFEAT_privileged feature bit is supported" meta-feature flag.
>> 
>> No, I don't view it that way - in the Linux ports, the meaning of
>> the respective config options is such that privileged includes
>> unprivileged, but that's a guest OS decision, not one the interface
>> should dictate.
> 
> Hmm, I suppose. I'm not sure it would be possible to implement a guest
> which was able to run as a dom0 but didn't by necessity also implement
> enough stuff to work as a domU (at least not far enough to print
> something useful).
> 
> Which reminds me -- when you boot a non-dom0 (but domU) capable kernel
> as dom0 does it not get far enough to print something to its console?
> IOW could we avoid this whole mess by "fixing" it in the guest?

Without "earlyprintk=xen" it likely won't get far enough. And
earlyprintk=xen really makes no sense on a DomU-only kernel, so
could even be unavailable. Further the guest likely wouldn't know of
a VGA or VESA fb (again because of being DomU-only), and hence it
may not have a usable console interface at all when booted as Dom0.

Jan


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