From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F25643D6CCB for ; Wed, 4 Mar 2026 19:55:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772654149; cv=none; b=VSlm7d+BACuZK5h+kUuItm9rMEQiU+TMuSqC8y4dwC/K4Mq0LPw/7XUo0iStHPKfxRO1lXaI11RYodbtFfUz7gRCgQynbENFTmfikfQ6l7ByioNkuslcGkPQ+9cnMjPuGax/S+Sci6htjo07nwClzmi5Wbz1WjLL2ym0QyMBk6k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772654149; c=relaxed/simple; bh=Gd9tyCTj2s7vSc2TwkwqjW1IW4A5Tzi7AvehUe9JJDA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=vE2HKD2z6f9MATBj6FZ8g7iOv9X3Vd+s32uQURspQaBxtEEnqE0U/MRzG9bQPOKeLmMwNTyYaDRvYctRDW2kkM7rCVlKWJ3QBC3JBPvNjOIXttG82MumB/2d7IvVtekmFyq2BNzY20hMed2iLY7ibPmlV7BD0iUKZo1JMvntLB4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=RJxCfF9q; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="RJxCfF9q" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ae44db60c2so40023765ad.2 for ; Wed, 04 Mar 2026 11:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772654146; x=1773258946; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=ld1CTX+5EMV5KR4I3tiAgS8iHnH1Pp/Xz4A9bG3MbFM=; b=RJxCfF9qsAQPzUCpGjIuzHiL9qG5QfNNoD4J5mSsFe9T2KM+wMnPHVZZx3H3IjLC7i LjAKZMtho8Fn6czQ0i8WvnUtfwekRa8y83tAuhoPtFxYC/doRU89BMJSmrlpJ1JvLYLB CaxS960wx4hbS7voKfUVfCUXQXGDemUmdE3hGHRG1acFIkwHT2oefj5iWwaiq9Rgp1L6 Q8K9ybR5JcswIUakfprsbkJKoFRZ8EQvbw/lpHPG01j7qJy+P/+Yfw9KtqTS8U7VMuzn uOByhpmKi1tdGosg/te9Kx/coiW4+dX4l299N4JfuM7/f05zNu/k8mxi6kye950gBXLP Eyqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772654146; x=1773258946; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=ld1CTX+5EMV5KR4I3tiAgS8iHnH1Pp/Xz4A9bG3MbFM=; b=LNyVgRhpfXNPBZ8Q/wOQNYECU6s+r6vEJmur7VhP0u2T1jkqtx4pmAIcRoNjYGtmd2 evepFD4hvJteRRXPWegg76c7bjnyjIBVQXyLSRqyUYRO/MQvYWHwHh0Y+qZsO/zfyC86 qcZT6OLrXM6ebV0FmXJMkvgyy02XxBNLToZQJf1k88+NbfhI8XrNTmrqOitUUgVkde4w +yYP3zXdBjJLi22BMdFTnCWalF3PfAkdrdtnYD1zf9OiOozEJJj0STNSuDpLkp9dkhTT eMaNlSFCZf0rCjuukm8dysGJE3tB6us3/JLulnV48Fh6oeZ6vSk0MHck8PTT4rG7jUAf 62Sw== X-Forwarded-Encrypted: i=1; AJvYcCXr9kozNM5qi6arAqTkLzUPmpfEekHpHY6lACaxWMKxiqFE/mgOXTwKvCyK2e1KSXHcdO7gnsy3dAo3Onc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy6p+wr5zHnswgydMMzYqmZ7v46RGIZbC93RGgPUakR3UnbsdC1 h01V4oRb+QSmpGtYqJIh8hwUpW2nuXr1h0wjpag9JxMVRlijZ2PfOKq9OG5E2u7EBlx6IsA4+IX A22LDyw== X-Received: from plot6.prod.google.com ([2002:a17:902:8c86:b0:2aa:d604:fb13]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f645:b0:2ae:4445:f397 with SMTP id d9443c01a7336-2ae6a9fd7ebmr31834575ad.16.1772654146212; Wed, 04 Mar 2026 11:55:46 -0800 (PST) Date: Wed, 4 Mar 2026 11:55:44 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260224005500.1471972-1-jmattson@google.com> <20260224005500.1471972-9-jmattson@google.com> Message-ID: Subject: Re: [PATCH v5 08/10] KVM: x86: nSVM: Save/restore gPAT with KVM_{GET,SET}_NESTED_STATE From: Sean Christopherson To: Yosry Ahmed Cc: Jim Mattson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Shuah Khan , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Yosry Ahmed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 04, 2026, Yosry Ahmed wrote: > On Wed, Mar 4, 2026 at 11:11=E2=80=AFAM Sean Christopherson wrote: > > > > On Wed, Mar 04, 2026, Jim Mattson wrote: > > > On Wed, Mar 4, 2026 at 9:11=E2=80=AFAM Sean Christopherson 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_vc= pu *vcpu, > > > > if (is_guest_mode(vcpu)) { > > > > kvm_state.hdr.svm.vmcb_pa =3D svm->nested.vmcb12_gp= a; > > > > if (nested_npt_enabled(svm)) { > > > > - kvm_state.hdr.svm.flags |=3D KVM_STATE_SVM_= VALID_GPAT; > > > > + kvm_state->flags |=3D KVM_STATE_NESTED_GPAT= _VALID; > > > > kvm_state.hdr.svm.gpat =3D svm->vmcb->save.= g_pat; > > > > } > > > > kvm_state.size +=3D KVM_STATE_NESTED_SVM_VMCB_SIZE; > > > > @@ -1914,7 +1914,8 @@ static int svm_set_nested_state(struct kvm_vc= pu *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 restri= cting 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_STA= TE 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 fi= xup. :-( >=20 > 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!