On 1/20/2022 5:17 PM, Paolo Bonzini wrote:
On 1/20/22 08:48, Like Xu wrote:
In the testcase "executing XSETBV with CR4.XSAVE=0",
- on the VMX, #UD delivery does not require vm-exit;
Not your fault, it would be nicer if the Intel manual told the truth;
it says: "The following instructions cause VM exits when they are
executed in VMX non-root operation: CPUID, GETSEC[1], INVD, and XSETBV."
Footnote [1] says "An execution of GETSEC causes an invalid-opcode
exception (#UD) if CR4.SMXE[Bit 14] = 0", and there is no such footnote
for XSETBV. Nevertheless, when tracing xsave.flat, I see that there's
a #UD vmexit and not an XSETBV vmexit:
qemu-kvm-1637698 [019] 758186.750321: kvm_entry:
vcpu 0, rip 0x4028b7
qemu-kvm-1637698 [019] 758186.750322: kvm_exit:
vcpu 0 reason EXCEPTION_NMI rip 0x40048d info1 0x0000000000000000 info2
0x0000000000000000 intr_info 0x80000306 error_code 0x00000000
qemu-kvm-1637698 [019] 758186.750324: kvm_emulate_insn:
0:40048d:0f 01 d1 (prot64)
qemu-kvm-1637698 [019] 758186.750325: kvm_inj_exception: #UD
(0x0)
So while my gut feeling that #UD would not cause a vmexit was correct,
technically I was reading the SDM incorrectly.
SDM also states
Certain exceptions have priority over VM exits. These include
invalid-opcode exception, faults based on privilege level,
and general-protection exceptions that are based on checking
I/O permission bits in the task-state segment(TSS)
in "Relative Priority of Faults and VM Exits"
So my understanding is that the architectural check always takes the
higher priority than VM exit.
Jun, can you have this fixed?
Paolo
- on the SVM, #UD is trapped but goes to the ud_interception() path;
