Re: [PATCH v3 1/7] KVM: SVM: Drop RAX check for SVM instructions from the emulator

[Yosry Ahmed]

On Sun, Mar 15, 2026 at 5:55 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On 3/13/26 01:10, Yosry Ahmed wrote:
> > Outside of forced emulation or code stream rewriting,
>
> But isn't that the point? Due to code stream rewriting or intentional
> usage of stale TLBs (so that the processor executes one instruction and
> the emulator another), the emulator cannot assume that it will "never be
> invoked with an actually illegal RAX".
>
> I realize that I'm late to the show, so I apologize in advance if this
> has been discussed before.

Thanks for chiming in. FWIW, I initially intended to fix this check
instead of removing it, the removal came after a discussion with Sean,
see https://lore.kernel.org/kvm/abH0RdnM29Xyh_4G@xxxxxxxxxx for more
context.

TL;DR is that the emulator support for VMRUN/VMLOAD/VMSAVE is
broken/unsupported anyway, beyond checking for intercepts and
pre-intercept exceptions (well, even that is broken), and the RAX
check should be after that architecturally.

The emulator isn't wired up to actually emulate these instructions.
Also, it performs the #GP on CPL check before the #UD on EFER.SVME
check, which is wrong. The right thing to do for the illegal RAX check
would be to move it after the intercept check, but we don't have an
execute() callback to put it in. I think what we really should do is
actually wire up the emulator to call into the intercept handlers for
VMRUN/VMLOAD/VMSAVE, such that it actually supports these
instructions, and the RAX check is done in this intercept handlers (or
at least will be after this series).

Given that the goal of this series is actually to stop injecting a
non-architectural #GP when KVM fails to read vmcb12, I didn't really
want to derail it anymore by making it emulator-focused. We can
probably do a follow-up on just improving the emulator support for
these instructions as I mentioned above, as that would take its own
series AFAICT.

The only reason this patch exists here is because the buggy RAX check
in the emulator results in injecting a non-architectural #GP on 52-bit
MAXPHYADDR platforms (the #NPF scenario described in the changelog).
So the check is blocking the goal of the series. I didn't really care
much whether we fixed it or removed it, but Sean did not want to fix
it and have the emulator directly peek into vCPU state, so removal it
was.

I hope this makes things clearer.