Re: [PATCH v9 00/22] Enable FRED with KVM VMX

[Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>]

On 2026-05-05 at 19:30:21 +0100, Andrew Cooper wrote:
>On 05/05/2026 7:04 pm, Maciej Wieczor-Retman wrote:
>> Hello!
>>
>>
>> On 2026-04-23 at 15:56:54 -0700, Xin Li wrote:
>>>> On Apr 23, 2026, at 7:35 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>>>> Here's one to get you started (untested as I haven't found suitable
>>>> hardware to test it on).
>>> Same here for me now :(
>> I ran David's selftest on a PTL laptop and ran into a couple of issues.
>>
>> ...
>>>> +
>>>> + /* Test 1: ICEBP (INT1) — should be EVENT_TYPE_PRIV_SWEXC (5) */
>>>> + fred_handler_called = false;
>>>> + asm volatile("lea 1f(%%rip), %0\n\t"
>>>> +     ".byte 0xf1\n\t"
>>>> +     "1:" : "=r"(expected_rip) :: "memory");
>>>> + check_fred_event(expected_rip, DB_VECTOR, EVENT_TYPE_PRIV_SWEXC,
>>>> + "ICEBP");
>>>> + GUEST_SYNC(0);
>> The above event type test seems to fail and return 0x3 instead of 0x5:
>>
>> Random seed: 0x6b8b4567
>> Testing FRED event types with EPT fault on stack
>> ==== Test Assertion Failure ====
>>   x86/int1_fred_test.c:120: event_type == expected_type
>>   pid=16646 tid=16646 errno=4 - Interrupted system call
>>      1  0x0000000000413349: assert_on_unhandled_exception at processor.c:659
>>      2  0x0000000000407d36: _vcpu_run at kvm_util.c:1703
>>      3   (inlined by) vcpu_run at kvm_util.c:1714
>>      4  0x0000000000403104: main at int1_fred_test.c:207
>>      5  0x00007ff8d4c2a1c9: ?? ??:0
>>      6  0x00007ff8d4c2a28a: ?? ??:0
>>      7  0x0000000000403314: _start at ??:?
>>   0x3 != 0x5 (event_type != expected_type)
>>
>> after a little digging I think the issue could be this in arch/x86/kvm/x86.h:
>>
>> 	static inline bool kvm_exception_is_soft(unsigned int nr)
>> 	{
>> 		return (nr == BP_VECTOR) || (nr == OF_VECTOR);
>> 	}
>>
>> Since ICEBP(INT1) results in a DB_VECTOR it's not take into account and the
>> check fails. Then in vmx_inject_exception() INTR_TYPE_HARD_EXCEPTION is picked
>> which is 0x3 when decoded.
>
>That's a real bug then.
>
>> I think you'd need to add another check in vmx_inject_exception() to handle that
>> DB_VECTOR too. Simply changing the event type if the vector is of DB_VECTOR type
>> fixes that problem but then the selftest fails in other places (assert
>> fred_handler_called and saved rip vs expected_rip). I didn't yet have the time
>> to figure out what could be wrong there, maybe you would have more of an idea :)
>
>#DB is intercepted to mitigate CVE-2015-8104 (systemwide DoS).  But, to
>start with, check that the test passes when #DB is not intercepted. 
>That's the basecase for architectural behaviour.

I take it you mean dropping the ICEBP selftest test case and just checking INT3
and INT $0x20? In that case the other two tests pass after a minor change -
namely in guest_code() the expected_rip needs to be volatile as well. Otherwise
there is a RIP mismatch.

Or did you mean I should check something else?

>When #DB is intercepted, the type in EXIT_INTR_INFO needs preserving and
>forwarding into ENTRY_INTR_INFO, because that is what distinguishes an
>ICEBP #DB from other #DBs.  There's no way of recovering this detail
>after the fact.
>
>On the injection side, some #DB's are traps and some are faults.  ICEBP
>will have a fault-like VMExit but need trap semantics, so like other
>soft interrupts, need INSN_LEN adding to %rip.  But, type=3 #DBs need to
>leave %rip unchanged.
>
>~Andrew

-- 
Kind regards
Maciej Wieczór-Retman