On Mon, Sep 17, 2018 at 12:07 PM, Jim Mattson <jmattson@xxxxxxxxxx> wrote: > When L0 enumerates support for an instruction not supported by the > physical CPU, it must emulate that instruction for L2 as well as for > L1. Take MOVBE, for example. If hardware reports that > CPUID.1:ECX.MOVBE[bit 22] is clear, but L0 sets the bit when emulating > CPUID for L1, then L0 is obligated to intercept #UD and emulate the > MOVBE instruction for L1. Furthermore, L0 is also obligated to > intercept #UD and emulate the MOVBE instruction for L2. Even if L1 > chooses to intercept #UD, L0 must be prepared to decode the > instruction and emulate MOVBE before deciding to reflect the #UD > VM-exit to L1. > > Rewriting the wrong hypercall instruction with the correct hypercall > instruction is not as clear-cut. One could argue that this is a > property of a kvm virtual CPU, and that L0 should always do > it. However, to avoid surprises, I've preserved the existing behavior > (right or wrong). Actually, I haven't completely preserved the existing behavior. Currently, if L1 intercepts #UD, then the wrong hypercall instruction will result in the #UD VM-exit being reflected to L1. However, if L1 does not intercept #UD, then L0 will try to rewrite the hypercall instruction with the correct one. It will try, but it will most likely fail, since the ewrite operation obeys the guest's page protections. A failure will result in a synthesized #PF being delivered to L2. With this change, if L1 doesn't intercept #UD, a synthesized #UD is delivered to L2. L0 will never try to rewrite the wrong hypercall instruction in L2, regardless of whether or not L1 intercepts #UD.
