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

["H. Peter Anvin" <hpa@zytor.com>]

On May 5, 2026 11:30:21 AM PDT, Andrew Cooper <andrew.cooper3@citrix.com> 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.
>>
>>>> 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

Also, a function that is accessed only from assembly should have the __visible annotation.