Re: [PATCH V2 2/4] KVM: SVM: Fix nested NPF injection to set PFERR_GUEST_{PAGE,FINAL}_MASK

[Sean Christopherson <seanjc@google.com>]

On Wed, Mar 04, 2026, Kevin Cheng wrote:
> On Tue, Feb 24, 2026 at 11:42 AM Sean Christopherson <seanjc@google.com> wrote:
> > This is all kinds of messy.  KVM _appears_ to still rely on the hardware-reported
> > address + error_code
> >
> >         if (vmcb->control.exit_code != SVM_EXIT_NPF) {
> >                 vmcb->control.exit_info_1 = fault->error_code;
> >                 vmcb->control.exit_info_2 = fault->address;
> >         }
> >
> > But then drops bits 31:0 in favor of the fault error code.  Then even more
> > bizarrely, bitwise-ORs bits 63:32 and WARNs if multiple bits in
> > PFERR_GUEST_FAULT_STAGE_MASK are set.  In practice, the bitwise-OR of 63:32 is
> > _only_ going to affect PFERR_GUEST_FAULT_STAGE_MASK, because the other defined
> > bits are all specific to SNP, and KVM doesn't support nested virtualization for
> > SEV+.
> >
> > So I don't understand why this isn't simply:
> >
> >         vmcb->control.exit_code = SVM_EXIT_NPF;
> >         vmcb->control.exit_info_1 = fault->error_code;
> >
> 
> Hmmm yes I do think it can be replaced by this but we would also need
> to grab the address from the walker. So
> 
>         vmcb->control.exit_code = SVM_EXIT_NPF;
>         vmcb->control.exit_info_1 = fault->error_code;
>         vmcb->control.exit_info_2 = fault->address;
> 
> For example, in the selftest that I wrote we should be populating the
> exit_info_2 with the faulting address from the walker, not the
> original hardware reported address which is related to IO.

Yeah, sorry for the confusion.  I wasn't saying _don't_ include the address, I
was just pointing out that the error_code handling can be much simpler.