Re: [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Ian Campbell <Ian.Campbell@citrix.com>]

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.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@citrix.com>
> CC: Tim Deegan <tim@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.