On 6/1/2026 4:10 PM, Nikunj A Dadhania wrote: > Sean Christopherson <[email protected]> writes: > >> +AMD folks >> >> On Thu, May 07, 2026, Sean Christopherson wrote: >>> On Thu, May 07, 2026, Andrew Cooper wrote: >>>> On 07/05/2026 3:08 pm, Sean Christopherson wrote: >>>>> On Thu, May 07, 2026, David Woodhouse wrote: >>>>>> From: David Woodhouse <[email protected]> >>>>>> >>>>>> ICEBP (INT1, opcode 0xF1) generates a #DB that is architecturally a >>>>>> trap, but on SVM it was not always intercepted. Unconditionally >>>>>> intercept ICEBP on SVM to match VMX behaviour and ensure correct >>>>>> event delivery semantics. >>>>>> >>>>>> Add two selftests exercising ICEBP: >>>>>> >>>>>> - int1_ept_test: verifies that ICEBP works correctly when the >>>>>> exception stack page is not present (EPT/NPT fault during #DB >>>>>> delivery). The IST stack is evicted via MADV_DONTNEED before >>>>>> executing INT1. >>>>>> >>>>>> - int1_task_gate_test: verifies ICEBP delivery through a 32-bit >>>>>> task gate, exercising the legacy task-switch path for #DB. >>>>>> >>>>>> Tested on Intel Sapphire Rapids and AMD Genoa. Without the SVM fix, >>>>>> int1_task_gate_test fails on AMD with EIP pointing at ICEBP instead >>>>>> of after it. With the fix, both tests pass on both platforms. >>>>> Hmm, but KVM unconditionally intercepts task switches. Is this >>>>> effectively working >>>>> around a bug in task_switch_interception()? >>>> >>>> Not really. It's a bug/misfeature in AMD CPUs. >>>> >>>> When you get TASK_SWITCH (which always has fault semantics), you look at >>>> the vectoring event type to decide whether it was logically caused by a >>>> trap, and therefore whether to move %rip forwards before entering the >>>> new task. >>>> >>>> AMD CPUs don't distinguish instruction-induced #DBs (i.e. ICEBP) from >>>> exception-induced #DBs (all others), and also don't report an >>>> instruction length for an ICEBP-induced TASK_SWITCH. >>> >>> Heh, that explains why I couldn't find an equivalent of >>> INTR_TYPE_PRIV_SW_EXCEPTION >>> in the SVM code. >> >> Dragging in a comment/concern Andrew raised offlist. If AMD doesn't provide >> or >> *allow* the equivalent of INTR_TYPE_PRIV_SW_EXCEPTION, i.e. type 5, then what >> happens when KVM needs to inject an INT1 #DB with FRED enabled? > > I'm checking internally to get clarification on this. Will follow up > once I have more details. Following up on my earlier response — this has been addressed in the AMD FRED Virtualization specification. Type 5 (privileged software exception) is now supported in both EXITINTINFO and EVENTINJ for FRED-enabled guests. Details are documented in the AMD FRED Virtualization spec (Rev 1.10): https://docs.amd.com/v/u/en-US/69191-PUB Regards, Nikunj
