Re: [PATCH] KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXIT

[Sean Christopherson <seanjc@google.com>]

On Wed, Feb 11, 2026, Yosry Ahmed wrote:
>  
> > So, with all of that in mind, I believe the best we can do is fully defer delivery
> > of the exception until it's actually injected, and then apply the quirk to the
> > relevant GET APIs.
> > @@ -5747,6 +5759,8 @@ static int kvm_vcpu_ioctl_x86_get_debugregs(struct kvm_vcpu *vcpu,
> >  	    vcpu->arch.guest_state_protected)
> >  		return -EINVAL;
> >  
> > +	kvm_handle_exception_payload_quirk(vcpu);
> > +
> >  	memset(dbgregs, 0, sizeof(*dbgregs));
> >  
> >  	BUILD_BUG_ON(ARRAY_SIZE(vcpu->arch.db) != ARRAY_SIZE(dbgregs->db));
> > @@ -12123,6 +12137,8 @@ static void __get_sregs_common(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
> >  	if (vcpu->arch.guest_state_protected)
> >  		goto skip_protected_regs;
> >  
> > +	kvm_handle_exception_payload_quirk(vcpu);
> > +
> 
> Hmm looking at this again, I realized it also affects the code path from
> store_regs(), I think we don't want to prematurely deliver exception
> payloads in that path.

Hrm, I actually think delivering the payload in store_regs() is the least awful
option.  E.g. a VMM that saves sregs on exit to userspace could elide KVM_GET_SREGS
when doing a save/restore.

In practice, it's all moot, because AFAICT nothing uses KVM_SYNC_X86_SREGS.

> So maybe it's best to move this to
> kvm_arch_vcpu_ioctl_get_sregs() and kvm_arch_vcpu_ioctl()?
> 
> The other option is to plumb a boolean that is only set to true in the
> ioctl code path.
> 
> >  	kvm_get_segment(vcpu, &sregs->cs, VCPU_SREG_CS);
> >  	kvm_get_segment(vcpu, &sregs->ds, VCPU_SREG_DS);
> >  	kvm_get_segment(vcpu, &sregs->es, VCPU_SREG_ES);
> > 
> > base-commit: 55671237401edd1ec59276b852b9361cc170915b
> > --