Re: [PATCH] KVM: SVM: Always intercept ICEBP, add INT1 selftests

[Nikunj A Dadhania]

Sean Christopherson <seanjc@xxxxxxxxxx> 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 <dwmw@xxxxxxxxxxxx>
>> > >>
>> > >> 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