On Tue, 2024-03-12 at 09:54 -0700, Sean Christopherson wrote: > On Tue, Mar 12, 2024, Kai Huang wrote: > > On 28/02/2024 12:20 pm, Paolo Bonzini wrote: > > > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > > > > > To support TDX, KVM is enhanced to operate with #VE. For TDX, KVM uses the > > > suppress #VE bit in EPT entries selectively, in order to be able to trap > > > non-present conditions. However, #VE isn't used for VMX and it's a bug > > > if it happens. To be defensive and test that VMX case isn't broken > > > introduce an option ept_violation_ve_test and when it's set, BUG the vm. > > > > I am wondering from HW's point of view, is it OK for the kernel to > > explicitly send #VE IPI, in which case, IIUC, the guest can legally get the > > #VE w/o being a TDX guest? > > Ooh, fun. Short answer: there's nothing to worry about here. > > Legally, no. Vectors 0-31 are reserved. However, I do _think_ the guest could > technically send IPIs on vectors 16-31, as the local APIC doesn't outright reject > such vectors. But such software would be in clear violation of the SDM. > > 11.5.2 Valid Interrupt Vectors > > The Intel 64 and IA-32 architectures define 256 vector numbers, ranging from > 0 through 255 (see Section 6.2, “Exception and Interrupt Vectors”). Local and > I/O APICs support 240 of these vectors (in the range of 16 to 255) as valid > interrupts. > > When an interrupt vector in the range of 0 to 15 is sent or received through > the local APIC, the APIC indicates an illegal vector in its Error Status > Register (see Section 11.5.3, “Error Handling”). The Intel 64 and IA-32 > architectures reserve vectors 16 through 31 for predefined interrupts, > exceptions, and Intel-reserved encodings (see Table 6-1). However, the local > APIC does not treat vectors in this range as illegal. > > When an illegal vector value (0 to 15) is written to an LVT entry and the delivery > mode is Fixed (bits 8-11 equal 0), the APIC may signal an illegal vector error, > without regard to whether the mask bit is set or whether an interrupt is actually > seen on the input. I hate the "may" here :-) > > where Table 6-1 defines the various exceptions, including #VE, and for vectors > 22-31 says "Intel reserved. Do not use." Vectors 32-255 are explicitly described > as "User Defined (Non-reserved) Interrupts" that can be generated via "External > interrupt or INT n instruction." > > However, INTn is far more interesting than IPIs, as INTn can definitely generate > interrupts for vectors 0-31, and the legality of software generating such interrupts > is questionable. E.g. KVM used to "forward" NMI VM-Exits to the kernel by doing > INTn with vector 2. > > Key word "interrupts"! IPIs are hardware interrupts, and INTn generates software > interrupts, neither of which are subject to exception bitmap interception: > > Exceptions (faults, traps, and aborts) cause VM exits based on the exception > bitmap (see Section 25.6.3). If an exception occurs, its vector (in the range > 0–31) is used to select a bit in the exception bitmap. If the bit is 1, a VM > exit occurs; if the bit is 0, the exception is delivered normally through the > guest IDT. This use of the exception bitmap applies also to exceptions generated > by the instructions INT1, INT3, INTO, BOUND, UD0, UD1, and UD2. > > with a footnote that further says: > > INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectively, > and not to INT n with value 1 or 3 for n. > > So while a misbehaving guest could generate a software interrupt on vector 20, > it would not be a true #VE, i.e. not an exception, and thus would not generate > an EXCEPTION_NMI VM-Exit. I.e. the KVM_BUG_ON() can't be triggered by the guest > (assuming hardware isn't broken). > Ah, right, software-interrupts but not exceptions. Thanks for the full explanation!
