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

["Nikunj A. Dadhania" <nikunj@amd.com>]

On 6/1/2026 4:10 PM, Nikunj A Dadhania wrote:
> Sean Christopherson <seanjc@google.com> 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@amazon.co.uk>
>>>>>>
>>>>>> 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