Re: [PATCH v2 1/6] KVM: SVM: Use maxphyaddr in emulator RAX check for VMRUN/VMLOAD/VMSAVE

[Yosry Ahmed]

On Fri, Mar 6, 2026 at 2:27 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Fri, Mar 6, 2026 at 1:09 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> > Architecturally, VMRUN/VMLOAD/VMSAVE should generate a #GP if the
> > physical address in RAX is not supported. check_svme_pa() hardcodes this
> > to checking that bits 63-48 are not set. This is incorrect on HW
> > supporting 52 bits of physical address space, so use maxphyaddr instead.
> >
> > Note that the host's maxphyaddr is used, not the guest, because the
> > emulator path for VMLOAD/VMSAVE is generally used when virtual
> > VMLOAD/VMSAVE is enabled AND a #NPF is generated. If a #NPF is not
> > generated, the CPU will inject a #GP based on the host's maxphyaddr.  So
> > this keeps the behavior consistent.
> >
> > If KVM wants to consistently inject a #GP based on the guest's
> > maxphyaddr, it would need to disabled virtual VMLOAD/VMSAVE and
> > intercept all VMLOAD/VMSAVE instructions to do the check.
> >
> > Also, emulating a smaller maxphyaddr for the guest than the host
> > generally doesn't work well, so it's not worth handling this.
>
> If we're going to throw in the towel on allow_smaller_maxphyaddr, the
> code should be removed.
>
> In any case, the check should logically be against the guest's
> maxphyaddr, because the VMLOAD/VMSAVE instruction executes in guest
> context.

Right, but I am trying to have the #GP check for VMLOAD/VMSAVE behave
consistently with vls=1, whether it's done by the hardware or the
emulator.

>
> Note that virtual VMLOAD/VMSAVE cannot be used if the guest's
> maxphyaddr doesn't match the host's maxphyaddr.

Not sure what you mean? Do you mean it wouldn't be correct to use it?
AFAICT that doesn't prevent it from being enabled.