On Fri, 2015-01-02 at 19:12 +0000, Andrew Cooper wrote: > supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 to > run in ring 0, but at the expense of not being able to start any domUs. > > As the x86_32 Xen build has been removed from tree, removing the remaining > supervisor_mode_kernel code. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > CC: Keir Fraser <k...@xen.org> > CC: Jan Beulich <jbeul...@suse.com> > CC: Ian Campbell <ian.campb...@citrix.com> > CC: Stefano Stabellini <stefano.stabell...@citrix.com> > CC: Tim Deegan <t...@xen.org> > > --- > > One complication is that PVH has reused XENFEAT_supervisor_mode_kernel with a > modified meaning, and the Linux PVH code actively uses the flag as to indicate > running as a PVH guest.
What is the modification? Doesn't a PVH kernel just use it to indicate that it should (or wants) run in ring0 instead of ring1/ring3? That was the original intention IIRC. Regardless, supervisor_mode_kernel was never anything more than a prototype, I'm pretty certain there can be no kernels out there relying on it, so rather than breaking pvh dom0 as you seem to do here I think it would be better to retcon the meaning of the flag as needed. > This causes an discontinuity between PVH and HVM guests, both of which run > their kernels with the PVH-taken meaning of XENFEAT_supervisor_mode_kernel. > > It also means that a dom0 kernel is unable to express "PVH-only" by requiring > this feature, as a 64bit Xen will validly reject an attempt to require a > 32bit-only Xen feature. I wouldn't describe XENFEAT_supervisor_mode_kernel as a "32-bit only Xen feature". It was only ever implemented for 32-bit, but conceptually it isn't specific to 32-bit but to any setup where PV requires you to run the kernel at a lower then normal privilege level. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
