On 17/06/20 00:43, Oliver Upton wrote: > - if (!nested_cpu_has2(vmcs12, SECONDARY_EXEC_DESC)) > - return X86EMUL_CONTINUE; > - > - /* FIXME: produce nested vmexit and return X86EMUL_INTERCEPTED. */ > + intercepted = nested_cpu_has2(vmcs12, SECONDARY_EXEC_DESC); > break; > [...] > + /* > + * The only uses of the emulator in VMX for instructions which may be > + * intercepted are port IO instructions, descriptor-table accesses, and > + * the RDTSCP instruction. As such, if the emulator has decoded an > + * instruction that is different from the VM-exit provided by hardware > + * it is likely that the TLB entry and page-table mapping for the > + * guest's RIP are out of sync. > + * > + * Rather than synthesizing a VM-exit into L1 for every possible > + * instruction just flush the TLB, resume L2, and let hardware generate > + * the appropriate VM-exit. > + */ So you're saying that (in the SECONDARY_EXEC_DESC case above for an example) this should have been handled earlier by nested_vmx_l1_wants_exit. But what about LGDT and friends from an MMIO address? I would say we could just not care, but an infinite #UD loop is an ugly failure mode. (Or perhaps it's just not my day for reviewing code...). Paolo
