Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
At 19:12 + on 02 Jan (1420222343), 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 Reviewed-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Mon, 2015-01-05 at 16:07 +, Andrew Cooper wrote: What usecase was supervisor_mode_kernel developed for? It seems counter-intuitive, but I can't find anything in the history explaining its use. It was a prototype from the pre-pvops days to see if it would be feasible to have a single kernel binary which ran either on Xen or on a stub hypervisor which ran it as native with little or no loss of performance^TM (e.g. for distro's convenience to avoid the multiple kernel issue). It never went beyond a prototype with Xen proper instead of the proposed stub hypervisor and then pvops came along and was a much more sensible idea... Considering the implications of running dom0 in ring0, pvops seems like a much more sensible idea. It wouldn't have been a dom0, it would have just been a native system which happened to use some Xen interfaces, the intention was never to be able to run guests or anything, just to allow distros to only support one binary. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Mon, 5 Jan 2015 15:35:27 + Andrew Cooper andrew.coop...@citrix.com wrote: On 05/01/15 15:16, Ian Campbell wrote: On Fri, 2015-01-02 at 19:12 +, 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. That flag has confused me too, and it was added later to pvh. Since, PVH guest is able to run in ring 0 ir-respective of the flag, imho, XENFEAT_supervisor_mode_kernel can be just removed. The important ones are really: XENFEAT_auto_translated_physmap XENFEAT_hvm_callback_vector thanks Mukesh ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Fri, 2015-01-02 at 19:12 +, 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
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On 05/01/15 15:16, Ian Campbell wrote: On Fri, 2015-01-02 at 19:12 +, 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. 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Mon, 2015-01-05 at 15:35 +, Andrew Cooper wrote: 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. Oh, good! 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. Conversely one could argue that it is a PV* only feature which makes no sense to an HVM guest (which I think is approximately what it means now) What usecase was supervisor_mode_kernel developed for? It seems counter-intuitive, but I can't find anything in the history explaining its use. It was a prototype from the pre-pvops days to see if it would be feasible to have a single kernel binary which ran either on Xen or on a stub hypervisor which ran it as native with little or no loss of performance^TM (e.g. for distro's convenience to avoid the multiple kernel issue). It never went beyond a prototype with Xen proper instead of the proposed stub hypervisor and then pvops came along and was a much more sensible idea... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On 05/01/15 15:41, Ian Campbell wrote: On Mon, 2015-01-05 at 15:35 +, Andrew Cooper wrote: 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. Oh, good! 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. Conversely one could argue that it is a PV* only feature which makes no sense to an HVM guest (which I think is approximately what it means now) This is going to cause problems with the effort to unify PVH and HVM into a single guest type, which is why I raised the point. The Linux PVH code is already using it as a PVH vs non-PVH flag. Either way - these are not problems which need fixing right now, but do need to be considered as the unification work progresses. What usecase was supervisor_mode_kernel developed for? It seems counter-intuitive, but I can't find anything in the history explaining its use. It was a prototype from the pre-pvops days to see if it would be feasible to have a single kernel binary which ran either on Xen or on a stub hypervisor which ran it as native with little or no loss of performance^TM (e.g. for distro's convenience to avoid the multiple kernel issue). It never went beyond a prototype with Xen proper instead of the proposed stub hypervisor and then pvops came along and was a much more sensible idea... Considering the implications of running dom0 in ring0, pvops seems like a much more sensible idea. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
