> UMIP (User-Mode Instruction Prevention) is a feature of future Intel
> processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT and SMSW from
> user-mode processes.
>
> The idea here is to use virtualization intercepts to emulate UMIP; it slows
> down the instructions when they're executed in ring 0, but they are really
> never executed in practice. On AMD systems it's possible to emulate it
> entirely; instead on Intel systems it's *almost* possible to emulate it,
> because SMSW doesn't cause a vmexit, and hence SMSW will not fault.
>
> This patch series provides the infrastructure and implements it on Intel. I
> tested it through kvm-unit-tests.
>
> Still I think the idea is interesting, even if it's buggy for current Intel
> processors. Any opinions?
Hi Paolo,
We intended to enable UMIP for KVM and found you had already worked on it.
Do you have any plan for the following patch set? It's there anything else you expect
us help to do?
Thanks!
Liang
On 13/12/2016 05:03, Li, Liang Z wrote:
> Hi Paolo,
>
> We intended to enable UMIP for KVM and found you had already worked on it.
> Do you have any plan for the following patch set? It's there anything else you expect
> us help to do?
Yes, I plan to resend these patches for 4.11.
Paolo
On 12/13/2016 7:03 PM, Paolo Bonzini wrote:
>
> On 13/12/2016 05:03, Li, Liang Z wrote:
>> Hi Paolo,
>>
>> We intended to enable UMIP for KVM and found you had already worked on it.
>> Do you have any plan for the following patch set? It's there anything else you expect
>> us help to do?
> Yes, I plan to resend these patches for 4.11.
Hi Paolo,
Previously we saw your RFC patches of UMIP sent out, and we would
like to try some unit test in Intel. I found a patch written by you in
https://patchwork.kernel.org/patch/9225929/, guess this is for the kvm
unit test(though I failed to git apply it directly).
And I wonder, when will it be integrated to kvm unit test repo?
Besides, is this all the test for UMIP unit test? I.e. do we need to
construct a scenario in the test to trigger vm exit and let hypervisor
inject a GP fault? - I did not see this scenario in this patch. Or any
other suggestions? :-)
Thanks
Yu
----- Original Message -----
> From: "Yu Zhang" <[email protected]>
> To: "Paolo Bonzini" <[email protected]>
> Cc: "qian ouyang" <[email protected]>, [email protected], [email protected]
> Sent: Wednesday, March 1, 2017 10:04:17 AM
> Subject: Re: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)
>
>
>
> On 12/13/2016 7:03 PM, Paolo Bonzini wrote:
> >
> > On 13/12/2016 05:03, Li, Liang Z wrote:
> >> Hi Paolo,
> >>
> >> We intended to enable UMIP for KVM and found you had already worked on it.
> >> Do you have any plan for the following patch set? It's there anything else
> >> you expect
> >> us help to do?
> > Yes, I plan to resend these patches for 4.11.
>
> Hi Paolo,
>
> Previously we saw your RFC patches of UMIP sent out, and we would
> like to try some unit test in Intel. I found a patch written by you in
> https://patchwork.kernel.org/patch/9225929/, guess this is for the kvm
> unit test(though I failed to git apply it directly).
> And I wonder, when will it be integrated to kvm unit test repo?
Probably together with the patches for UMIP support and emulation.
> Besides, is this all the test for UMIP unit test? I.e. do we need to
> construct a scenario in the test to trigger vm exit and let hypervisor
> inject a GP fault? - I did not see this scenario in this patch. Or any
> other suggestions? :-)
The unit test only tests that UMIP works as advertised; if the host processor
does not support UMIP, it will test the hypervisor emulation path. Whenever
UMIP support is added to KVM, we will probably add a module parameter so that
we can force UMIP emulation path even on processor that have native support.
Paolo
On 3/1/2017 5:04 PM, Yu Zhang wrote:
>
>
> On 12/13/2016 7:03 PM, Paolo Bonzini wrote:
>>
>> On 13/12/2016 05:03, Li, Liang Z wrote:
>>> Hi Paolo,
>>>
>>> We intended to enable UMIP for KVM and found you had already worked
>>> on it.
>>> Do you have any plan for the following patch set? It's there
>>> anything else you expect
>>> us help to do?
>> Yes, I plan to resend these patches for 4.11.
>
> Hi Paolo,
>
> Previously we saw your RFC patches of UMIP sent out, and we would
> like to try some unit test in Intel. I found a patch written by you in
> https://patchwork.kernel.org/patch/9225929/, guess this is for the kvm
> unit test(though I failed to git apply it directly).
> And I wonder, when will it be integrated to kvm unit test repo?
> Besides, is this all the test for UMIP unit test? I.e. do we need to
> construct a scenario in the test to trigger vm exit and let hypervisor
> inject a GP fault? - I did not see this scenario in this patch. Or any
> other suggestions? :-)
>
Hi Paolo, any suggestions?
Sorry for the disturb. :)
Yu
> Thanks
> Yu
>
On 10/03/2017 09:02, Yu Zhang wrote:
>> Besides, is this all the test for UMIP unit test? I.e. do we need to
>> construct a scenario in the test to trigger vm exit and let hypervisor
>> inject a GP fault? - I did not see this scenario in this patch. Or any
>> other suggestions? :-)
>
> Hi Paolo, any suggestions?
> Sorry for the disturb. :)
Hi, you get the scenario where a vmexit is triggered by the hypervisor
if you run the unit test on a machine that lacks UMIP support.
We can also add a module parameter to force emulation, so that it will
be possible to test UMIP emulation on newer processors too.
Paolo
On 3/10/2017 4:36 PM, Paolo Bonzini wrote:
>
> On 10/03/2017 09:02, Yu Zhang wrote:
>>> Besides, is this all the test for UMIP unit test? I.e. do we need to
>>> construct a scenario in the test to trigger vm exit and let hypervisor
>>> inject a GP fault? - I did not see this scenario in this patch. Or any
>>> other suggestions? :-)
>> Hi Paolo, any suggestions?
>> Sorry for the disturb. :)
> Hi, you get the scenario where a vmexit is triggered by the hypervisor
> if you run the unit test on a machine that lacks UMIP support.
>
> We can also add a module parameter to force emulation, so that it will
> be possible to test UMIP emulation on newer processors too.
Thanks for your reply, Paolo. :-)
Well, my previous understanding is that there might be a situation on a
machine with UMIP
feature:
1> when an APP in VM runs instructions such as sgdt addrA,
2> and the addrA may cause anVM exit(e.g. ept violation),
3> next, the emulator in hypervisor need to inject a GP fault to the VM.
Is this situation possible?
This is the case I'd like to test, yet do not know to construct the
scenario.
But as to the scenario you described, I do not quit understand.
I mean, on a host which do not support UMIP, although hypervisor may
intercept cpuid and
provide an emulated cr4 to guest, how does it guarantee those
instructions in VM will cause
a VM exit?
Yu
> Paolo
>
On 3/10/2017 5:31 PM, Yu Zhang wrote:
>
>
> On 3/10/2017 4:36 PM, Paolo Bonzini wrote:
>>
>> On 10/03/2017 09:02, Yu Zhang wrote:
>>>> Besides, is this all the test for UMIP unit test? I.e. do we
>>>> need to
>>>> construct a scenario in the test to trigger vm exit and let hypervisor
>>>> inject a GP fault? - I did not see this scenario in this patch. Or any
>>>> other suggestions? :-)
>>> Hi Paolo, any suggestions?
>>> Sorry for the disturb. :)
>> Hi, you get the scenario where a vmexit is triggered by the hypervisor
>> if you run the unit test on a machine that lacks UMIP support.
>>
>> We can also add a module parameter to force emulation, so that it will
>> be possible to test UMIP emulation on newer processors too.
>
> Thanks for your reply, Paolo. :-)
>
> Well, my previous understanding is that there might be a situation on
> a machine with UMIP
> feature:
> 1> when an APP in VM runs instructions such as sgdt addrA,
> 2> and the addrA may cause anVM exit(e.g. ept violation),
> 3> next, the emulator in hypervisor need to inject a GP fault to the VM.
> Is this situation possible?
> This is the case I'd like to test, yet do not know to construct the
> scenario.
>
Sorry, Paolo. I may have misunderstanding on this.
In intel SDM chapt 25, it says "Certain exceptions have priority over VM
exits. These include
invalid-opcode exceptions, faults based on privilege level...".
So in above case, it is GP fault in VM that should happen, instead of VM
exit, right?
> But as to the scenario you described, I do not quit understand.
> I mean, on a host which do not support UMIP, although hypervisor may
> intercept cpuid and
> provide an emulated cr4 to guest, how does it guarantee those
> instructions in VM will cause
> a VM exit?
For this scenario, vm exit should be caused if "descriptor-table
exiting? VM-execution control is 1,
then hypervisor should have opportunity to do the force emulation.
Is my new understanding correct?
Another question is, what if host do have the UMIP feature, and the
"descriptor-table exiting? VM-execution
control is 1? Will a GP fault in VM happen, or a VM exit?
Thanks
Yu
> Yu
>> Paolo
>>
>
>
On 10/03/2017 10:31, Yu Zhang wrote:
>> We can also add a module parameter to force emulation, so that it will
>> be possible to test UMIP emulation on newer processors too.
>
> Thanks for your reply, Paolo. :-)
>
> Well, my previous understanding is that there might be a situation on a
> machine with UMIP
> feature:
> 1> when an APP in VM runs instructions such as sgdt addrA,
> 2> and the addrA may cause anVM exit(e.g. ept violation),
> 3> next, the emulator in hypervisor need to inject a GP fault to the VM.
> Is this situation possible?
No, the guest will execute the instruction again after the vmexit.
> But as to the scenario you described, I do not quit understand.
> I mean, on a host which do not support UMIP, although hypervisor may
> intercept cpuid and
> provide an emulated cr4 to guest, how does it guarantee those
> instructions in VM will cause a VM exit?
All instructions except SMSW can be trapped using descriptor table vmexits.
Paolo