From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported Date: Mon, 5 Jan 2015 15:16:33 +0000 Message-ID: <1420470993.28863.31.camel@citrix.com> References: <1420225943-20530-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1420225943-20530-1-git-send-email-andrew.cooper3@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Stefano Stabellini , Tim Deegan , Keir Fraser , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org 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 > CC: Keir Fraser > CC: Jan Beulich > CC: Ian Campbell > CC: Stefano Stabellini > CC: Tim Deegan > > --- > > 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.