In fact, even if L1 does intercept #UD, it may not be prepared to emulate MOVBE.
On Fri, Dec 1, 2017 at 3:00 PM, Jim Mattson <jmattson@xxxxxxxxxx> 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.
>
>
> 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.
