about fully UMIP support in Xen

about fully UMIP support in Xen

[Yu Zhang]

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

Re: about fully UMIP support in Xen

[Jan Beulich]

>>> On 19.04.17 at 10:48, <yu.c.zhang@linux.intel.com> 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

Re: about fully UMIP support in Xen

[Yu Zhang]

On 4/19/2017 5:18 PM, Jan Beulich wrote:
>>>> On 19.04.17 at 10:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

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, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Yu Zhang]

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, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> wrote:
> On 4/19/2017 5:18 PM, Jan Beulich wrote:
>>>>> On 19.04.17 at 10:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Yu Zhang]

On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> wrote:
>> On 4/19/2017 5:18 PM, Jan Beulich wrote:
>>>>>> On 19.04.17 at 10:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 19.04.17 at 13:44, <yu.c.zhang@linux.intel.com> wrote:
> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

On 19/04/17 14:34, Jan Beulich wrote:
>>>> On 19.04.17 at 13:44, <yu.c.zhang@linux.intel.com> wrote:
>> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Yu Zhang]

On 4/19/2017 9:34 PM, Jan Beulich wrote:
>>>> On 19.04.17 at 13:44, <yu.c.zhang@linux.intel.com> wrote:
>> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

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, <yu.c.zhang@linux.intel.com> wrote:
>>> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 19.04.17 at 15:49, <andrew.cooper3@citrix.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 19.04.17 at 15:58, <andrew.cooper3@citrix.com> 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, <yu.c.zhang@linux.intel.com> wrote:
>>>> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

On 19/04/17 15:07, Jan Beulich wrote:
>>>> On 19.04.17 at 15:58, <andrew.cooper3@citrix.com> 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, <yu.c.zhang@linux.intel.com> wrote:
>>>>> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

On 19/04/17 15:06, Jan Beulich wrote:
>>>> On 19.04.17 at 15:49, <andrew.cooper3@citrix.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 19.04.17 at 16:17, <andrew.cooper3@citrix.com> wrote:
> On 19/04/17 15:06, Jan Beulich wrote:
>>>>> On 19.04.17 at 15:49, <andrew.cooper3@citrix.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

On 19/04/17 15:27, Jan Beulich wrote:
>>>> On 19.04.17 at 16:17, <andrew.cooper3@citrix.com> wrote:
>> On 19/04/17 15:06, Jan Beulich wrote:
>>>>>> On 19.04.17 at 15:49, <andrew.cooper3@citrix.com> 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: about fully UMIP support in Xen

[Yu Zhang]

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, <andrew.cooper3@citrix.com> 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, <yu.c.zhang@linux.intel.com> wrote:
>>>>>> On 4/19/2017 7:19 PM, Jan Beulich wrote:
>>>>>>>>>> On 19.04.17 at 11:48, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 20.04.17 at 09:15, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Yu Zhang]

On 4/20/2017 5:47 PM, Jan Beulich wrote:
>>>> On 20.04.17 at 09:15, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Jan Beulich]

>>> On 20.04.17 at 11:53, <yu.c.zhang@linux.intel.com> wrote:
> On 4/20/2017 5:47 PM, Jan Beulich wrote:
>>>>> On 20.04.17 at 09:15, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Yu Zhang]

On 4/20/2017 6:01 PM, Jan Beulich wrote:
>>>> On 20.04.17 at 11:53, <yu.c.zhang@linux.intel.com> wrote:
>> On 4/20/2017 5:47 PM, Jan Beulich wrote:
>>>>>> On 20.04.17 at 09:15, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Andrew Cooper]

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, <yu.c.zhang@linux.intel.com> wrote:
>>> On 4/20/2017 5:47 PM, Jan Beulich wrote:
>>>>>>> On 20.04.17 at 09:15, <yu.c.zhang@linux.intel.com> 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: about fully UMIP support in Xen

[Yu Zhang]

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, <yu.c.zhang@linux.intel.com> wrote:
>>>> On 4/20/2017 5:47 PM, Jan Beulich wrote:
>>>>>>>> On 20.04.17 at 09:15, <yu.c.zhang@linux.intel.com> 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