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

[Maciej Wieczor-Retman]

On 2026-05-07 at 08:49:27 +0100, David Woodhouse wrote:
>On Tue, 2026-05-05 at 22:20 +0200, Maciej Wieczor-Retman wrote:
>> 
>> 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.
>
>I don't understand the part about making expected_rip volatile. Are the
>asm constraints there not correct? If not I'd rather *fix* them than
>use 'volatile' to paper over it. I can't see the issue though.
>
>Can you show the generated asm both with and without it?

---------- not volatile ---------------- | -------------- volatile -----------------
#APP						#APP
# 156 "x86/int1_fred_test.c" 1			# 156 "x86/int1_fred_test.c" 1
	lea 1f(%rip), %rdi		      |		lea 1f(%rip), %rax
	int3						int3
	1:						1:
# 0 "" 2					# 0 "" 2
.LVL42:					      <
	.loc 3 159 2 view .LVU146	      <
#NO_APP						#NO_APP
					      >		movq	%rax, 8(%rsp)
					      >		.loc 3 159 2 view .LVU146
					      >		movq	8(%rsp), %rdi
	movl	$6, %edx				movl	$6, %edx
	movl	$3, %esi				movl	$3, %esi
	call	check_fred_event.isra.0			call	check_fred_event.isra.0

I think that when the FRED event happens it doesn't save RDI and overwrites it
before going into check_fred_event. In the volatile case it is saved to the
stack before check_fred_event() (.loc 159 is the check_fred_event() call).

The below does work, it generates pretty much the same assembly as the volatile
expected_rip. Do you like it? I'm not sure if it can be simplified better?

	asm volatile("lea 1f(%%rip), %%rax\n\t"
		     "movq %%rax, %0\n\t"
		     "int3\n\t"
		     "1:" : "=m"(expected_rip) :: "memory", "rax");

-- 
Kind regards
Maciej Wieczór-Retman