On Wed, Mar 04, 2026, Yosry Ahmed wrote: > On Wed, Mar 4, 2026 at 11:11 AM Sean Christopherson <[email protected]> wrote: > > > > On Wed, Mar 04, 2026, Jim Mattson wrote: > > > On Wed, Mar 4, 2026 at 9:11 AM Sean Christopherson <[email protected]> > > > wrote: > > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > > > > index 991ee4c03363..099bf8ac10ee 100644 > > > > --- a/arch/x86/kvm/svm/nested.c > > > > +++ b/arch/x86/kvm/svm/nested.c > > > > @@ -1848,7 +1848,7 @@ static int svm_get_nested_state(struct kvm_vcpu > > > > *vcpu, > > > > if (is_guest_mode(vcpu)) { > > > > kvm_state.hdr.svm.vmcb_pa = svm->nested.vmcb12_gpa; > > > > if (nested_npt_enabled(svm)) { > > > > - kvm_state.hdr.svm.flags |= > > > > KVM_STATE_SVM_VALID_GPAT; > > > > + kvm_state->flags |= KVM_STATE_NESTED_GPAT_VALID; > > > > kvm_state.hdr.svm.gpat = svm->vmcb->save.g_pat; > > > > } > > > > kvm_state.size += KVM_STATE_NESTED_SVM_VMCB_SIZE; > > > > @@ -1914,7 +1914,8 @@ static int svm_set_nested_state(struct kvm_vcpu > > > > *vcpu, > > > > > > > > if (kvm_state->flags & ~(KVM_STATE_NESTED_GUEST_MODE | > > > > KVM_STATE_NESTED_RUN_PENDING | > > > > - KVM_STATE_NESTED_GIF_SET)) > > > > + KVM_STATE_NESTED_GIF_SET | > > > > + KVM_STATE_NESTED_GPAT_VALID)) > > > > return -EINVAL; > > > > > > Unless I'm missing something, this breaks forward compatibility > > > completely. An older kernel will refuse to accept a nested state blob > > > with GPAT_VALID set. > > > > Argh, so we've painted ourselves into an impossible situation by > > restricting the > > set of valid flags. I.e. VMX's omission of checks on unknown flags is a > > feature, > > not a bug. > > > > Chatted with Jim offlist, and he pointed out that KVM's standard way to > > deal with > > this is to make setting the flag opt-in, e.g. > > KVM_CAP_X86_TRIPLE_FAULT_EVENT and > > KVM_CAP_EXCEPTION_PAYLOAD. > > > > As much as I want to retroactively change KVM's documentation to state doing > > KVM_SET_NESTED_STATE with data that didn't come from KVM_GET_NESTED_STATE is > > unsupported, that feels too restrictive and could really bite us in the > > future. > > And it doesn't help if there's already userspace that's putting garbage > > into the > > header. > > > > So yeah, I don't see a better option than adding yet another capability. > > > > Can you send a new version based on `kvm-x86 next`? (give me ~hour to drop > > these > > and push). This has snowballed beyond what I'm comfortable doing as fixup. > > :-( > > Will the current patches still be reachable through > kvm-x86-next-2026.03.03? I imagine Jim will want to pull those and > change them directly as they have all your fixups (rather than > reconstructing them).
Oh, yeah! I was actually going to self-respond with that suggestion, then squirrel!
