Re: [PATCH v3 03/10] KVM: selftests: Use an array for guest_regs (and fix offsets)

[Sean Christopherson <seanjc@google.com>]

On Fri, Jul 24, 2026, Yosry Ahmed wrote:
> On Fri, Jul 24, 2026 at 8:33 AM Sean Christopherson <seanjc@google.com> wrote:
> Oh I wanted to, but the compiler wouldn't let me use enum values
> directly in the preprocessor, see:
> https://lore.kernel.org/kvm/CAO9r8zPz8WbijVN6mgLb8OaU6=tNSSz1NgNBjZCsC36D4+TO+w@mail.gmail.com/.
> 
> I can do an enum *and* macros using enum values if you prefer so, like:
> 
> #define __GUEST_REGS_RAX 0
> ...
> 
> enum guest_regs {
>     GUEST_REGS_RAX = __GUEST_REGS_RAX,
>     ...
>     NR_GUEST_REGS,
> };

I would much rather follow KUT's lib/x86/virt.h, and provide asm constraints for
the offsets.  Actually, my vote is to copy+paste KUT's entire approach, and provide:

  struct guest_regs {
	u64 rax;
	u64 rcx;
	u64 rdx;
	u64 rbx;
	/*
	 * Use RSP's index to hold CR2, as RSP isn't manually context switched
	 * by software in any relevant flows.
	 *
	 * FIXME: Actually context switch CR2 on Intel.
	 */
	u64 cr2;
	u64 rbp;
	u64 rsi;
	u64 rdi;
	u64 r8;
	u64 r9;
	u64 r10;
	u64 r11;
	u64 r12;
	u64 r13;
	u64 r14;
	u64 r15;
	u64 rflags;
  };

Using an array for the GPRs is only valuable when the code *needs* to index the
GPRs based on their index, e.g. like KVM needs to do when emulating instructions.
But for "normal" software, using an array just makes the code kludgy.

E.g. this

	vmcb->save.rip = (u64)guest_rip;
	vmcb->save.rsp = (u64)svm->stack;
	guest_regs.rdi = (u64)svm;

versus

	vmcb->save.rip = (u64)guest_rip;
	vmcb->save.rsp = (u64)svm->stack;
	guest_regs[X86_REGS_RDI] = (u64)svm;