Re: [Xen-devel] about fully UMIP support in Xen
On 4/20/2017 6:23 PM, Andrew Cooper wrote: On 20/04/17 11:10, Yu Zhang wrote: On 4/20/2017 6:01 PM, Jan Beulich wrote: On 20.04.17 at 11:53, wrote: On 4/20/2017 5:47 PM, Jan Beulich wrote: On 20.04.17 at 09:15, wrote: And back to the schedule of this feature, are you working on it? Or any specific plan? Well, the HVM side is basically ready (as said, the single hunk needed to support UMIP when hardware supports it could be easily split off of my emulation patch). For the PV side I don't currently have any plans to do any work. Thanks, Jan. So do you have plan to push the HVM support in Xen 4.10? We're moving in circles, it feels. My patch depends on Andrew making progress. Breaking out the one mentioned hunk could of course be done at any time, if we have indication that UMIP hardware support will actually arrive and it becomes unlikely for the patch to be able to go in as a whole in time for 4.10. I can understand. And please let me know if there's any help we can offer here in Intel. :-) I have no immediate plans to do any UMIP work, again because I lack any hardware to suitably test it on. If Intel have time, exposing hardware UMIP support to HVM guests would be useful work, and hopefully trivial to do. (Ideally with an XTF regression test.) Got it. We have simics to emulate the new cpu platform. So we can take over this part. As to the PV support, I'm not sure if we have time to do so in the short time, but it's not urgent for us. :) Yu ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 20/04/17 11:10, Yu Zhang wrote: > > > On 4/20/2017 6:01 PM, Jan Beulich wrote: > On 20.04.17 at 11:53, wrote: >>> On 4/20/2017 5:47 PM, Jan Beulich wrote: >>> On 20.04.17 at 09:15, wrote: > And back to the schedule of this feature, are you working on it? > Or any > specific plan? Well, the HVM side is basically ready (as said, the single hunk needed to support UMIP when hardware supports it could be easily split off of my emulation patch). For the PV side I don't currently have any plans to do any work. >>> Thanks, Jan. So do you have plan to push the HVM support in Xen 4.10? >> We're moving in circles, it feels. My patch depends on Andrew >> making progress. Breaking out the one mentioned hunk could >> of course be done at any time, if we have indication that UMIP >> hardware support will actually arrive and it becomes unlikely >> for the patch to be able to go in as a whole in time for 4.10. > > I can understand. And please let me know if there's any help we can > offer here in Intel. :-) I have no immediate plans to do any UMIP work, again because I lack any hardware to suitably test it on. If Intel have time, exposing hardware UMIP support to HVM guests would be useful work, and hopefully trivial to do. (Ideally with an XTF regression test.) ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/20/2017 6:01 PM, Jan Beulich wrote: On 20.04.17 at 11:53, wrote: On 4/20/2017 5:47 PM, Jan Beulich wrote: On 20.04.17 at 09:15, wrote: And back to the schedule of this feature, are you working on it? Or any specific plan? Well, the HVM side is basically ready (as said, the single hunk needed to support UMIP when hardware supports it could be easily split off of my emulation patch). For the PV side I don't currently have any plans to do any work. Thanks, Jan. So do you have plan to push the HVM support in Xen 4.10? We're moving in circles, it feels. My patch depends on Andrew making progress. Breaking out the one mentioned hunk could of course be done at any time, if we have indication that UMIP hardware support will actually arrive and it becomes unlikely for the patch to be able to go in as a whole in time for 4.10. I can understand. And please let me know if there's any help we can offer here in Intel. :-) Yu Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 20.04.17 at 11:53, wrote: > On 4/20/2017 5:47 PM, Jan Beulich wrote: > On 20.04.17 at 09:15, wrote: >>> And back to the schedule of this feature, are you working on it? Or any >>> specific plan? >> Well, the HVM side is basically ready (as said, the single hunk needed >> to support UMIP when hardware supports it could be easily split off of >> my emulation patch). For the PV side I don't currently have any plans >> to do any work. > > Thanks, Jan. So do you have plan to push the HVM support in Xen 4.10? We're moving in circles, it feels. My patch depends on Andrew making progress. Breaking out the one mentioned hunk could of course be done at any time, if we have indication that UMIP hardware support will actually arrive and it becomes unlikely for the patch to be able to go in as a whole in time for 4.10. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/20/2017 5:47 PM, Jan Beulich wrote: On 20.04.17 at 09:15, wrote: And back to the schedule of this feature, are you working on it? Or any specific plan? Well, the HVM side is basically ready (as said, the single hunk needed to support UMIP when hardware supports it could be easily split off of my emulation patch). For the PV side I don't currently have any plans to do any work. Thanks, Jan. So do you have plan to push the HVM support in Xen 4.10? Is there anything we can do here in Intel? Traditionally PV hasn't been of much interest to Intel, but if you mean to support that (with or without exposure to the guest) then that's certainly something you may want to look into. Well, we have not planed to support the PV yet. But we can have an evaluation internally, and see if we have resource to do so. Yu Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 20.04.17 at 09:15, wrote: > And back to the schedule of this feature, are you working on it? Or any > specific plan? Well, the HVM side is basically ready (as said, the single hunk needed to support UMIP when hardware supports it could be easily split off of my emulation patch). For the PV side I don't currently have any plans to do any work. > Is there anything we can do here in Intel? Traditionally PV hasn't been of much interest to Intel, but if you mean to support that (with or without exposure to the guest) then that's certainly something you may want to look into. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/19/2017 10:09 PM, Andrew Cooper wrote: On 19/04/17 15:07, Jan Beulich wrote: On 19.04.17 at 15:58, wrote: On 19/04/17 14:50, Yu Zhang wrote: On 4/19/2017 9:34 PM, Jan Beulich wrote: On 19.04.17 at 13:44, wrote: On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48, wrote: Does hypervisor need to differentiate dom0 kernel and its user space? If we want to para-virtualize the feature, then yes. Otherwise we can't assume the guest kernel would deal with user mode faults, so we'd have to. Arguably there could be a non-default mode in which we don't (forcing such applications to get a signal or crash). For UMIP is to be para-virtualized, is it OK to give dom0 kernel the physical value if instructions are triggered in the kernel? Why would you want to special case Dom0 here? I don't see anything wrong with giving Dom0 the real values, but since you'll have to not give DomU-s the real values, you'd then add more code to treat Dom0 specially. Simply give everyone fake values. Oh. So in such case should return 0 to the dom0 kernel I guess? Here come a dumb question: does other pv domain also run in ring 3 in vmx root mode, or simply in vmx non-root ring 0? :) PV guests execute exclusively in non-root mode. In root mode, you mean. I do. (oops. Sorry.) Thanks a lot, Andrew & Jan. And back to the schedule of this feature, are you working on it? Or any specific plan? Is there anything we can do here in Intel? B.R. Yu ~Andrew Jan 32bit PV guest kernels execute in ring 1. 64bit PV guest kernels execute in ring 3. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 19/04/17 15:27, Jan Beulich wrote: On 19.04.17 at 16:17, wrote: >> On 19/04/17 15:06, Jan Beulich wrote: >> On 19.04.17 at 15:49, wrote: If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace should be bounced to the kernel, and #GPs from kernel space (as it is ring-deprivileged) must be emulated and execute successfully. If Xen is using UMIP to protect itself, it needs to emulate and fake up the information to both guest userspace and kernelspace. If both Xen and the PV kernel turn on UMIP, Xen needs to bounce userspace #GPs to the guest kernel, and fake up information for the guest kernel. >>> I disagree in one point: If the guest kernel enabled UMIP, it being >>> PV it should take care not to execute any of the covered insns (it >>> has no use for them anyway). I see no reason to emulate anything >>> in that case - emulation is needed only to keep _unaware_ >>> environments working. >> That will involve someone ensuring that new PVops get introduced and used. >> >> Amongst other things, the current Linux doublefault handler uses sgdt. > But a PV guest would never get to see a #DF. It currently doesn’t, but that is a mishap of the current PV ABI behaviour. A PV guest *should* see things like #NP for missing entries in its virtual IDT or non-present segments, rather than the current domain_crash() it gets, and with that comes the expectation of faults combining to inject #DF. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 19.04.17 at 16:17, wrote: > On 19/04/17 15:06, Jan Beulich wrote: > On 19.04.17 at 15:49, wrote: >>> If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace >>> should be bounced to the kernel, and #GPs from kernel space (as it is >>> ring-deprivileged) must be emulated and execute successfully. >>> >>> If Xen is using UMIP to protect itself, it needs to emulate and fake up >>> the information to both guest userspace and kernelspace. >>> >>> If both Xen and the PV kernel turn on UMIP, Xen needs to bounce >>> userspace #GPs to the guest kernel, and fake up information for the >>> guest kernel. >> I disagree in one point: If the guest kernel enabled UMIP, it being >> PV it should take care not to execute any of the covered insns (it >> has no use for them anyway). I see no reason to emulate anything >> in that case - emulation is needed only to keep _unaware_ >> environments working. > > That will involve someone ensuring that new PVops get introduced and used. > > Amongst other things, the current Linux doublefault handler uses sgdt. But a PV guest would never get to see a #DF. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 19/04/17 15:06, Jan Beulich wrote: On 19.04.17 at 15:49, wrote: >> If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace >> should be bounced to the kernel, and #GPs from kernel space (as it is >> ring-deprivileged) must be emulated and execute successfully. >> >> If Xen is using UMIP to protect itself, it needs to emulate and fake up >> the information to both guest userspace and kernelspace. >> >> If both Xen and the PV kernel turn on UMIP, Xen needs to bounce >> userspace #GPs to the guest kernel, and fake up information for the >> guest kernel. > I disagree in one point: If the guest kernel enabled UMIP, it being > PV it should take care not to execute any of the covered insns (it > has no use for them anyway). I see no reason to emulate anything > in that case - emulation is needed only to keep _unaware_ > environments working. That will involve someone ensuring that new PVops get introduced and used. Amongst other things, the current Linux doublefault handler uses sgdt. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 19/04/17 15:07, Jan Beulich wrote: On 19.04.17 at 15:58, wrote: >> On 19/04/17 14:50, Yu Zhang wrote: >>> >>> On 4/19/2017 9:34 PM, Jan Beulich wrote: >>> On 19.04.17 at 13:44, wrote: > On 4/19/2017 7:19 PM, Jan Beulich wrote: > On 19.04.17 at 11:48, wrote: >>> Does hypervisor need to differentiate dom0 kernel and its >>> user space? >> If we want to para-virtualize the feature, then yes. Otherwise >> we can't assume the guest kernel would deal with user mode faults, >> so we'd have to. Arguably there could be a non-default mode in >> which we don't (forcing such applications to get a signal or crash). > For UMIP is to be para-virtualized, is it OK to give dom0 kernel the > physical value > if instructions are triggered in the kernel? Why would you want to special case Dom0 here? I don't see anything wrong with giving Dom0 the real values, but since you'll have to not give DomU-s the real values, you'd then add more code to treat Dom0 specially. Simply give everyone fake values. >>> Oh. So in such case should return 0 to the dom0 kernel I guess? >>> >>> Here come a dumb question: does other pv domain also run in ring 3 in >>> vmx root mode, >>> or simply in vmx non-root ring 0? :) >> PV guests execute exclusively in non-root mode. > In root mode, you mean. I do. (oops. Sorry.) ~Andrew > > Jan > >> 32bit PV guest kernels execute in ring 1. >> 64bit PV guest kernels execute in ring 3. >> >> ~Andrew > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 19.04.17 at 15:58, wrote: > On 19/04/17 14:50, Yu Zhang wrote: >> >> >> On 4/19/2017 9:34 PM, Jan Beulich wrote: >> On 19.04.17 at 13:44, wrote: On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48, wrote: >> Does hypervisor need to differentiate dom0 kernel and its >> user space? > If we want to para-virtualize the feature, then yes. Otherwise > we can't assume the guest kernel would deal with user mode faults, > so we'd have to. Arguably there could be a non-default mode in > which we don't (forcing such applications to get a signal or crash). For UMIP is to be para-virtualized, is it OK to give dom0 kernel the physical value if instructions are triggered in the kernel? >>> Why would you want to special case Dom0 here? I don't see >>> anything wrong with giving Dom0 the real values, but since you'll >>> have to not give DomU-s the real values, you'd then add more >>> code to treat Dom0 specially. Simply give everyone fake values. >> >> Oh. So in such case should return 0 to the dom0 kernel I guess? >> >> Here come a dumb question: does other pv domain also run in ring 3 in >> vmx root mode, >> or simply in vmx non-root ring 0? :) > > PV guests execute exclusively in non-root mode. In root mode, you mean. Jan > 32bit PV guest kernels execute in ring 1. > 64bit PV guest kernels execute in ring 3. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 19.04.17 at 15:49, wrote: > If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace > should be bounced to the kernel, and #GPs from kernel space (as it is > ring-deprivileged) must be emulated and execute successfully. > > If Xen is using UMIP to protect itself, it needs to emulate and fake up > the information to both guest userspace and kernelspace. > > If both Xen and the PV kernel turn on UMIP, Xen needs to bounce > userspace #GPs to the guest kernel, and fake up information for the > guest kernel. I disagree in one point: If the guest kernel enabled UMIP, it being PV it should take care not to execute any of the covered insns (it has no use for them anyway). I see no reason to emulate anything in that case - emulation is needed only to keep _unaware_ environments working. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 19/04/17 14:50, Yu Zhang wrote: > > > On 4/19/2017 9:34 PM, Jan Beulich wrote: > On 19.04.17 at 13:44, wrote: >>> On 4/19/2017 7:19 PM, Jan Beulich wrote: >>> On 19.04.17 at 11:48, wrote: > Does hypervisor need to differentiate dom0 kernel and its > user space? If we want to para-virtualize the feature, then yes. Otherwise we can't assume the guest kernel would deal with user mode faults, so we'd have to. Arguably there could be a non-default mode in which we don't (forcing such applications to get a signal or crash). >>> For UMIP is to be para-virtualized, is it OK to give dom0 kernel the >>> physical value >>> if instructions are triggered in the kernel? >> Why would you want to special case Dom0 here? I don't see >> anything wrong with giving Dom0 the real values, but since you'll >> have to not give DomU-s the real values, you'd then add more >> code to treat Dom0 specially. Simply give everyone fake values. > > Oh. So in such case should return 0 to the dom0 kernel I guess? > > Here come a dumb question: does other pv domain also run in ring 3 in > vmx root mode, > or simply in vmx non-root ring 0? :) PV guests execute exclusively in non-root mode. 32bit PV guest kernels execute in ring 1. 64bit PV guest kernels execute in ring 3. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/19/2017 9:34 PM, Jan Beulich wrote: On 19.04.17 at 13:44, wrote: On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48, wrote: Does hypervisor need to differentiate dom0 kernel and its user space? If we want to para-virtualize the feature, then yes. Otherwise we can't assume the guest kernel would deal with user mode faults, so we'd have to. Arguably there could be a non-default mode in which we don't (forcing such applications to get a signal or crash). For UMIP is to be para-virtualized, is it OK to give dom0 kernel the physical value if instructions are triggered in the kernel? Why would you want to special case Dom0 here? I don't see anything wrong with giving Dom0 the real values, but since you'll have to not give DomU-s the real values, you'd then add more code to treat Dom0 specially. Simply give everyone fake values. Oh. So in such case should return 0 to the dom0 kernel I guess? Here come a dumb question: does other pv domain also run in ring 3 in vmx root mode, or simply in vmx non-root ring 0? :) Thanks Yu And if the instructions are triggered in dom0 user space, the spec requires a #GP fault, and we can return 0 to the application in the #GP fault handler, is it OK? Yes, I think so. But the fundamental rule is - make it match what native Linux does in that case. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 19/04/17 14:34, Jan Beulich wrote: On 19.04.17 at 13:44, wrote: >> On 4/19/2017 7:19 PM, Jan Beulich wrote: >> On 19.04.17 at 11:48, wrote: Does hypervisor need to differentiate dom0 kernel and its user space? >>> If we want to para-virtualize the feature, then yes. Otherwise >>> we can't assume the guest kernel would deal with user mode faults, >>> so we'd have to. Arguably there could be a non-default mode in >>> which we don't (forcing such applications to get a signal or crash). >> For UMIP is to be para-virtualized, is it OK to give dom0 kernel the >> physical value >> if instructions are triggered in the kernel? > Why would you want to special case Dom0 here? I don't see > anything wrong with giving Dom0 the real values, but since you'll > have to not give DomU-s the real values, you'd then add more > code to treat Dom0 specially. Simply give everyone fake values. > >> And if the instructions are triggered in dom0 user space, the spec >> requires a #GP >> fault, and we can return 0 to the application in the #GP fault handler, >> is it OK? > Yes, I think so. But the fundamental rule is - make it match what > native Linux does in that case. The attack scenario for PV guests is different. The point of UMIP there is to protect Xen against guests, including guest kernels. If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace should be bounced to the kernel, and #GPs from kernel space (as it is ring-deprivileged) must be emulated and execute successfully. If Xen is using UMIP to protect itself, it needs to emulate and fake up the information to both guest userspace and kernelspace. If both Xen and the PV kernel turn on UMIP, Xen needs to bounce userspace #GPs to the guest kernel, and fake up information for the guest kernel. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 19.04.17 at 13:44, wrote: > On 4/19/2017 7:19 PM, Jan Beulich wrote: > On 19.04.17 at 11:48, wrote: >>> Does hypervisor need to differentiate dom0 kernel and its >>> user space? >> If we want to para-virtualize the feature, then yes. Otherwise >> we can't assume the guest kernel would deal with user mode faults, >> so we'd have to. Arguably there could be a non-default mode in >> which we don't (forcing such applications to get a signal or crash). > > For UMIP is to be para-virtualized, is it OK to give dom0 kernel the > physical value > if instructions are triggered in the kernel? Why would you want to special case Dom0 here? I don't see anything wrong with giving Dom0 the real values, but since you'll have to not give DomU-s the real values, you'd then add more code to treat Dom0 specially. Simply give everyone fake values. > And if the instructions are triggered in dom0 user space, the spec > requires a #GP > fault, and we can return 0 to the application in the #GP fault handler, > is it OK? Yes, I think so. But the fundamental rule is - make it match what native Linux does in that case. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48, wrote: On 4/19/2017 5:18 PM, Jan Beulich wrote: On 19.04.17 at 10:48, wrote: I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not have logic to expose UMIP feature to guests - you have sent out one in https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html to emulate the cpuid leaf, but seems it was only a software solution and have not get merged yet. So I wonder do you have any specific plan to fully support the UMIP, i.e. in Xen 4.10? :-) It would be nice, but I think there are caveats: While PV guests _shouldn't_ use any of the affected instructions, we can't blindly assume they don't. Hence we'd have to emulate them (producing to be determined data, e.g. all zeros). Luckily we don't have to care about VM86 mode, as for code running there emulating the instructions would be mandatory (as they're e.g. needed for CPU family detection, since the recommended approach to tell [iirc] 286 from 386 doesn't reliably work there). Thanks, Jan. You mean if UMIP is enabled in xen, and dom0 triggers affected instructions, 0 should be returned? Yes. Does hypervisor need to differentiate dom0 kernel and its user space? If we want to para-virtualize the feature, then yes. Otherwise we can't assume the guest kernel would deal with user mode faults, so we'd have to. Arguably there could be a non-default mode in which we don't (forcing such applications to get a signal or crash). Thanks, Jan. For UMIP is to be para-virtualized, is it OK to give dom0 kernel the physical value if instructions are triggered in the kernel? And if the instructions are triggered in dom0 user space, the spec requires a #GP fault, and we can return 0 to the application in the #GP fault handler, is it OK? Yu Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 19.04.17 at 11:48, wrote: > On 4/19/2017 5:18 PM, Jan Beulich wrote: > On 19.04.17 at 10:48, wrote: >>> I saw that commit 8c14e5f provides emulations for UMIP affected >>> instructions. But realized that xen does not have logic to expose UMIP >>> feature to guests - you have sent out one in >>> https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html >>> to emulate the cpuid leaf, but seems it was only a software solution and >>> have not get merged yet. >>> So I wonder do you have any specific plan to fully support the UMIP, >>> i.e. in Xen 4.10? :-) >> It would be nice, but I think there are caveats: While PV guests >> _shouldn't_ use any of the affected instructions, we can't blindly >> assume they don't. Hence we'd have to emulate them (producing >> to be determined data, e.g. all zeros). Luckily we don't have to >> care about VM86 mode, as for code running there emulating the >> instructions would be mandatory (as they're e.g. needed for CPU >> family detection, since the recommended approach to tell [iirc] >> 286 from 386 doesn't reliably work there). > > Thanks, Jan. > You mean if UMIP is enabled in xen, and dom0 triggers affected > instructions, 0 should > be returned? Yes. > Does hypervisor need to differentiate dom0 kernel and its > user space? If we want to para-virtualize the feature, then yes. Otherwise we can't assume the guest kernel would deal with user mode faults, so we'd have to. Arguably there could be a non-default mode in which we don't (forcing such applications to get a signal or crash). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/19/2017 5:59 PM, Andrew Cooper wrote: On 19/04/17 10:48, Yu Zhang wrote: On 4/19/2017 5:18 PM, Jan Beulich wrote: On 19.04.17 at 10:48, wrote: I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not have logic to expose UMIP feature to guests - you have sent out one in https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html to emulate the cpuid leaf, but seems it was only a software solution and have not get merged yet. So I wonder do you have any specific plan to fully support the UMIP, i.e. in Xen 4.10? :-) It would be nice, but I think there are caveats: While PV guests _shouldn't_ use any of the affected instructions, we can't blindly assume they don't. Hence we'd have to emulate them (producing to be determined data, e.g. all zeros). Luckily we don't have to care about VM86 mode, as for code running there emulating the instructions would be mandatory (as they're e.g. needed for CPU family detection, since the recommended approach to tell [iirc] 286 from 386 doesn't reliably work there). Thanks, Jan. You mean if UMIP is enabled in xen, and dom0 triggers affected instructions, 0 should be returned? Does hypervisor need to differentiate dom0 kernel and its user space? For HVM guests the feature is of no interest to Xen itself anyway, i.e. all we'd need is allow them to enable the CR4 bit (which my emulation patch did as a side effect, but that patch has been deferred until after Andrew manages to put in some more CPUID work; that single hunk could certainly be split out if desired). By "CPUID work", I guess you changes needed in the xen/tools/gen-cpuid.py, not just emulating one to the guest, right? There are two angles here. The easy part of CPUID work is to expose it to PV and HVM guests, and this has yet to be done but shouldn't be hard. The more complicated part, which needs the toolstack CPUID modifications I want to do, is to be able to fake up UMIP to HVM guests on non-UMIP capable hardware. Thanks, Andrew. Our expectation is to get this feature into xen upstream in this year. Considering the xen release schedule, I guess it means to get the easy part accepted in xen 4.10. So I wonder, do you have plan to do this? Any assistance needed from Intel? :) Yu ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 19/04/17 10:48, Yu Zhang wrote: > > > On 4/19/2017 5:18 PM, Jan Beulich wrote: > On 19.04.17 at 10:48, wrote: >>> I saw that commit 8c14e5f provides emulations for UMIP affected >>> instructions. But realized that xen does not have logic to expose UMIP >>> feature to guests - you have sent out one in >>> https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html >>> >>> to emulate the cpuid leaf, but seems it was only a software solution >>> and >>> have not get merged yet. >>> So I wonder do you have any specific plan to fully support the >>> UMIP, >>> i.e. in Xen 4.10? :-) >> It would be nice, but I think there are caveats: While PV guests >> _shouldn't_ use any of the affected instructions, we can't blindly >> assume they don't. Hence we'd have to emulate them (producing >> to be determined data, e.g. all zeros). Luckily we don't have to >> care about VM86 mode, as for code running there emulating the >> instructions would be mandatory (as they're e.g. needed for CPU >> family detection, since the recommended approach to tell [iirc] >> 286 from 386 doesn't reliably work there). > > Thanks, Jan. > You mean if UMIP is enabled in xen, and dom0 triggers affected > instructions, 0 should > be returned? Does hypervisor need to differentiate dom0 kernel and its > user space? > >> For HVM guests the feature is of no interest to Xen itself anyway, >> i.e. all we'd need is allow them to enable the CR4 bit (which my >> emulation patch did as a side effect, but that patch has been >> deferred until after Andrew manages to put in some more CPUID >> work; that single hunk could certainly be split out if desired). > > By "CPUID work", I guess you changes needed in the > xen/tools/gen-cpuid.py, > not just emulating one to the guest, right? There are two angles here. The easy part of CPUID work is to expose it to PV and HVM guests, and this has yet to be done but shouldn't be hard. The more complicated part, which needs the toolstack CPUID modifications I want to do, is to be able to fake up UMIP to HVM guests on non-UMIP capable hardware. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
On 4/19/2017 5:18 PM, Jan Beulich wrote: On 19.04.17 at 10:48, wrote: I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not have logic to expose UMIP feature to guests - you have sent out one in https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html to emulate the cpuid leaf, but seems it was only a software solution and have not get merged yet. So I wonder do you have any specific plan to fully support the UMIP, i.e. in Xen 4.10? :-) It would be nice, but I think there are caveats: While PV guests _shouldn't_ use any of the affected instructions, we can't blindly assume they don't. Hence we'd have to emulate them (producing to be determined data, e.g. all zeros). Luckily we don't have to care about VM86 mode, as for code running there emulating the instructions would be mandatory (as they're e.g. needed for CPU family detection, since the recommended approach to tell [iirc] 286 from 386 doesn't reliably work there). Thanks, Jan. You mean if UMIP is enabled in xen, and dom0 triggers affected instructions, 0 should be returned? Does hypervisor need to differentiate dom0 kernel and its user space? For HVM guests the feature is of no interest to Xen itself anyway, i.e. all we'd need is allow them to enable the CR4 bit (which my emulation patch did as a side effect, but that patch has been deferred until after Andrew manages to put in some more CPUID work; that single hunk could certainly be split out if desired). By "CPUID work", I guess you changes needed in the xen/tools/gen-cpuid.py, not just emulating one to the guest, right? Yu Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] about fully UMIP support in Xen
>>> On 19.04.17 at 10:48, wrote: >I saw that commit 8c14e5f provides emulations for UMIP affected > instructions. But realized that xen does not have logic to expose UMIP > feature to guests - you have sent out one in > https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html > to emulate the cpuid leaf, but seems it was only a software solution and > have not get merged yet. >So I wonder do you have any specific plan to fully support the UMIP, > i.e. in Xen 4.10? :-) It would be nice, but I think there are caveats: While PV guests _shouldn't_ use any of the affected instructions, we can't blindly assume they don't. Hence we'd have to emulate them (producing to be determined data, e.g. all zeros). Luckily we don't have to care about VM86 mode, as for code running there emulating the instructions would be mandatory (as they're e.g. needed for CPU family detection, since the recommended approach to tell [iirc] 286 from 386 doesn't reliably work there). For HVM guests the feature is of no interest to Xen itself anyway, i.e. all we'd need is allow them to enable the CR4 bit (which my emulation patch did as a side effect, but that patch has been deferred until after Andrew manages to put in some more CPUID work; that single hunk could certainly be split out if desired). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] about fully UMIP support in Xen
Hi Jan, I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not have logic to expose UMIP feature to guests - you have sent out one in https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html to emulate the cpuid leaf, but seems it was only a software solution and have not get merged yet. So I wonder do you have any specific plan to fully support the UMIP, i.e. in Xen 4.10? :-) Thanks Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
