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

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

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.

>> 
>> From bd465aabebcb124e09a26fe9f4c861354febabe4 Mon Sep 17 00:00:00 2001
>> From: David Woodhouse <dwmw@amazon.co.uk>
>> Date: Thu, 23 Apr 2026 15:20:11 +0100
>> Subject: [PATCH] KVM: selftests: Add FRED event type classification test
>> 
>> +static void __used fred_handler(struct fred_stack_frame *frame)
>> +{
>> + fred_ss_value = frame->ss;
>> + fred_saved_rip = frame->rip;
>> + fred_handler_called = true;
>> +}

fred_handler() has problems getting linked:

	/usr/bin/ld: /home/maciej/linux/tools/testing/selftests/kvm/x86/int1_fred_test.o: in function `fred_entrypoint_kernel':
	int1_fred_test.c:(.text+0x104): undefined reference to `fred_handler'
	collect2: error: ld returned 1 exit status

I guess the .pushsection below makes it a different translation unit? Because
getting rid of the static keyword takes care of the problem for me.

>> +
>> +/*
>> + * FRED entry points. MSR_IA32_FRED_CONFIG points to the page-aligned
>> + * base. Ring 3 events enter at base+0, ring 0 events at base+0x100.
>> + * Since ICEBP executes in ring 0, the CPU enters at fred_entrypoint
>> + * + 256 = fred_entrypoint_kernel.
>> + */
>> +extern void fred_entrypoint(void);
>> +
>> +asm(
>> + ".pushsection .text\n"
>> + ".global fred_entrypoint\n"
>> + ".balign 4096\n"
>> +"fred_entrypoint:\n"
>> + /* Ring 3 entry — unused, no userspace in this test */
>> + "ud2\n"
>> + /* Pad to +256 for ring 0 entry */
>> + ".org fred_entrypoint + 256, 0xcc\n"
>> +"fred_entrypoint_kernel:\n"
>> + "movq %rsp, %rdi\n"
>> + "call fred_handler\n"
>> + ".byte 0xf2, 0x0f, 0x01, 0xca\n" /* ERETS */
>> + ".popsection\n"
>> +);
>> +
...
>> +
>> + /* 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.

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 :)

-- 
Kind regards
Maciej Wieczór-Retman