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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 05/01/15 15:16, Ian Campbell wrote:
> 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.

Answering out-of-order

This patch has no functional change WRT PVH.  The hunk commented on is
simply changed via indentation due to the removal of the conditional it
is in.  It was never been possible for a PVH kernel boot with
"!XENFEAT_supervisor_mode_kernel" in its feature string.

If retcon'ing this feature flag is acceptable then the problem goes
away, as can the commented hunk.  However, given the meaning of the
flag, it really should be advertised to plain HVM guests as well,
because their kernel does run in ring0.  At that point, it becomes more
of a general "running in an hvm container" flag.

What usecase was supervisor_mode_kernel developed for?  It seems
counter-intuitive, but I can't find anything in the history explaining
its use.

~Andrew