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

[Jim Mattson]

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.

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