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

[Jim Mattson]

On Tue, Mar 17, 2026 at 6:15 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> Il lun 16 mar 2026, 14:49 Yosry Ahmed <yosry@xxxxxxxxxx> ha scritto:
> >
> > 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.
>
> Agreed about that, just ripping it out completely would be fine. It's
> only if the emulation happens that it has to be complete.
>
> > 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.
>
> Agreed.
>
> > 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).
>
> Yeah, that part was clearly broken when physical address bits broke
> AMD's 48-bit limit (and I don't think the details of what is
> considered an invalid physical address are part of the architectural
> description, for example some SMM ranges are carved out by the
> VMRUN/VMLOAD/VMSAVE microcode).

IIUC, VLS is broken because it applies the host's microarchitectural
physical address restrictions to untranslated *guest* physical
addresses. Is that right?