On 02/12/17 01:00, Jim Mattson wrote:
How does this change interact with commit 84cffe499b94 ("kvm: Emulate MOVBE")?
If the hardware doesn't support MOVBE, but L0 sets CPUID.01H:ECX.MOVBE
in L1's emulated CPUID information, then L1 is likely to pass that
CPUID bit through to L2. L2 will expect MOVBE to work, but if L1
doesn't intercept #UD, then any MOVBE instruction executed in L2 will
raise #UD, and the exception will be delivered in L2.
Nice catch.
When I considered the functionality of the original commit which I
attempted to fix (commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD
while in guest mode")), my patch made sense as a more complete and
better fix.
However, both my patch and the original patch don't seem to consider the
issue you present here. I completely agree.
Maybe it was better just reverting my patch and commit ae1f57670703. I
think the attempt of that patch was to make L0 not simulate behaviour it
simulates for L1 in L2 as-well. but after reading your reply, I think
that it is a desired behaviour...
-Liran
On Fri, Nov 10, 2017 at 1:37 PM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote:
2017-11-06 16:15+0200, Liran Alon:
When running L2, #UD should be intercepted by L1 or just forwarded
directly to L2. It should not reach L0 x86 emulator.
Therefore, set intercept for #UD only based on L1 exception-bitmap.
Also add WARN_ON_ONCE() on L0 #UD intercept handlers to make sure
it is never reached while running L2.
This improves commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD while
in guest mode") by removing an unnecessary exit from L2 to L0 on #UD
when L1 doesn't intercept it.
In addition, SVM L0 #UD intercept handler doesn't handle correctly the
case it is raised from L2. In this case, it should forward the #UD to
guest instead of x86 emulator. As done in VMX #UD intercept handler.
This commit fixes this issue as-well.
Signed-off-by: Liran Alon <liran.alon@xxxxxxxxxx>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@xxxxxxxxxx>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
---
Applied, thanks.
