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. Regards, Nikunj
