[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH, v2] add privileged/unprivileged kernel feature indication
On Thu, 2011-07-21 at 09:16 +0100, Jan Beulich wrote: > >>> On 21.07.11 at 10:01, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote: > > On Wed, 2011-07-20 at 13:50 +0100, Jan Beulich wrote: > >> >>> 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. > > > > At the risk of repeating myself -- which functionality does domU require > > which is not also already necessary for a dom0 -- at least to the point > > of failing gracefully during boot? > > Graceful failure requires access to some user visible output device. A > Dom0-only kernel may e.g. not have any frontend drivers (particularly > no xenfb one, and the guest and/or kernel config may not allow other > virtualized output mechanisms). Your Linux side patch sets the unprivileged guest feature independently of CONFIG_XEN_FRAMEBUFFER and/or CONFIG_HVC_XEN so the proposed interface is already providing opportunities for confusion/ambiguity. > > 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 side decision to omit sch code on the understanding that the disadvantage will be less error reporting when a minimal kernel suiting a particular need is used in some other context. > > If we choose to do so we can decree that a dom0-only capable guest must > > also have sufficient domU functionality to print a message when running > > as domU and if they choose not to do this then it only impacts that > > guest and its users (which IMHO provides sufficient pressure on guest > > implementers to do the right thing). > > > > You say it is a Linux notion that dom0 implies domU but I am not aware > > of any PV OS which supports dom0 that doesn't also support domU, do you > > have specific examples of OSes which are dom0-only? > > No, I'm not aware of any existing ones, but I also wasn't in favor of > the move to imply unprivileged capabilities when Linux is configured > as privileged guest (iirc this wasn't the case from the very beginning). > > And again, imo an interface like the hypervisor's shouldn't dictate any > kind of policy on the guest OSes. The only policy here is "if you want to be user friendly you must minimally arrange to output a simple domU console message indicating lack of domU support if you support dom0 operation only". That's not so much a policy as pushing responsibility down into the guest kernel in an extremely unlikely configuration. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |