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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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.
>
>>> 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.

The problem is, being static, fred_handler() is eligible to be optimised
away, because the compiler can't see that the asm() refers to it.

Dropping static is the right fix to make.

GCC 15 can now do references out of global asm() to identify the symbols
they use, but it's going to be years before this capability is safe to
use generally.

>
>>> +
>>> +/*
>>> + * 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.

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.

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