Re: [PATCH v7 26/26] KVM: selftest: Add a selftest for VMRUN/#VMEXIT with unmappable vmcb12

[Yosry Ahmed]

On Thu, Mar 5, 2026 at 4:05 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Thu, Mar 5, 2026 at 2:52 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> > On Thu, Mar 5, 2026 at 2:30 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Mar 2, 2026 at 4:43 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > > >
> > > > Add a test that verifies that KVM correctly injects a #GP for nested
> > > > VMRUN and a shutdown for nested #VMEXIT, if the GPA of vmcb12 cannot be
> > > > mapped.
> > > >
> > > > Signed-off-by: Yosry Ahmed <yosry@xxxxxxxxxx>
> > > > ...
> > > > +       /*
> > > > +        * Find the max legal GPA that is not backed by a memslot (i.e. cannot
> > > > +        * be mapped by KVM).
> > > > +        */
> > > > +       maxphyaddr = kvm_cpuid_property(vcpu->cpuid, X86_PROPERTY_MAX_PHY_ADDR);
> > > > +       max_legal_gpa = BIT_ULL(maxphyaddr) - PAGE_SIZE;
> > > > +       vcpu_alloc_svm(vm, &nested_gva);
> > > > +       vcpu_args_set(vcpu, 2, nested_gva, max_legal_gpa);
> > > > +
> > > > +       /* VMRUN with max_legal_gpa, KVM injects a #GP */
> > > > +       vcpu_run(vcpu);
> > > > +       TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
> > > > +       TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
> > > > +       TEST_ASSERT_EQ(uc.args[1], SYNC_GP);
> > >
> > > Why would this raise #GP? That isn't architected behavior.
> >
> > I don't see architected behavior in the APM for what happens if VMRUN
> > fails to load the VMCB from memory. I guess it should be the same as
> > what would happen if a PTE is pointing to a physical address that
> > doesn't exist? Maybe #MC?
>
> Reads from non-existent memory return all 1's

Today I learned :) Do all x86 CPUs do this?

> so I would expect a #VMEXIT with exitcode VMEXIT_INVALID.

This would actually simplify the logic, as it would be the same
failure mode as failed consistency checks. That being said, KVM has
been injecting a #GP when it fails to map vmcb12 since the beginning.

It also does the same thing for VMSAVE/VMLOAD, which seems to also not
be architectural. This would be more annoying to handle correctly
because we'll need to copy all 1's to the relevant fields in vmcb12 or
vmcb01.

Sean, what do you want us to do here?