From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.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 5CB573DA5A8 for ; Wed, 4 Mar 2026 19:11:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772651480; cv=none; b=Ifl3Et4gNCtReTTCfJBHvr25CFKu1zdUHjAdzDqwXdV+gEjPb4ivxdPWMPzCUR2XBDb2jKUA5lRygsvoeHueQcodl718GpeGqdrgq1/Qt+2U6GL7UnbwXbntxgdN5U0pH4vmXoC7st4XMSfkQY8J/pHOJbaHHjlVKXsi6bmfRh8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772651480; c=relaxed/simple; bh=dRdL2NEwVuHOVBc3bIuWCDPU1wF737rdFjwwockVEVo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=lI+rOxPjTAq9ZGG/3Wc1/1N53tk+s9PcpBpz9IDg0T/rI9Eu8BhjLIwWMmQ3hRbqUFwgVhbZcainJA780VuZzxPzYNoD69uBrLUGvtI6FR5d5d8hkLsca4z5wJG+U1zd45Xz99VbgfoWYNT5POpv4vGQLv0y6L0Gp/SYe1kQw38= 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=nCWwHQJU; arc=none smtp.client-ip=209.85.215.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="nCWwHQJU" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b630b4d8d52so4571012a12.3 for ; Wed, 04 Mar 2026 11:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772651476; x=1773256276; 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=q9OtHjmtJSBf+k0JgdOZ0/RBQj404Jf3L0+cEK8R2TI=; b=nCWwHQJUjRE6jQLOq9GFTzmMyUzekx/2f9EN4E1w6/QGurn6/tE0uE08liEXT65LNs 3YE8SlFy4S5E/vtP6TjetPtrqDe5Xsc8jQLDzjDbDL4+UkFIRsNzCl+m0oeczXDGi6EZ fzR3792m5HNL8Y2BnV5LECe9LVHqsNY6Yy0wt7Bw07cJm+9GORWRPTMtRNYFNExRf2ch 9Q4Tbp4EOHvqiLDrSjXoCazUVT/ZTiD05UyydkC2IEJwPfDLjvgRARKL05V9XAFt+xJ8 UxCBoc6SJ2koITEbngAK8jtokUYYxR+DIyIhtRd0yDVtF+krcMCMJ5GgirAN7sZraNrc xOXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772651476; x=1773256276; 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=q9OtHjmtJSBf+k0JgdOZ0/RBQj404Jf3L0+cEK8R2TI=; b=emGFS/pBDBiwLhDoA5P7wZdTERLauivdl8o1Op8Hh5bvOrTEsBjs47MmPbh0uN0aPB Hrwenfc+3gcTn2GZ/2oGMEhVqGqsBqSyPx0SsZyMLDmL36C9FocqtUTlFwRyK4UakRiF 4ZWC7ooWodSrnkuvKFKrkzTUIHi+RxjULssxqx/956N7SZ6liRZg7s1J7faHl1ArBI6s krbRlZ/TB7hpaKfQKB+AvMaBbltEdXZmP/RybKa3yaSjpZt1rOFPQ/eBm4wef1vKnk4z hYZXxL+TWcxnRbhsqF+JpRd+A1p8eT2rrU5TpEZPobUye4tfYr4Iz1Wj6OVAz6dwHOxa feQQ== X-Forwarded-Encrypted: i=1; AJvYcCUggFWLtrY0HHQiQfWv5kyqI3Bp4eSRW0qcRbxRxz09ShxN298pQaep8csKxSCZHXT2SXg80cpjSY1qFYI=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0fJWTcDxl+HBnQxsmFdzjoj56yu8HcnxUFpxdRjYEJgGA/lm5 GWF+odvL0i4xA+mQyGGIvnkfz8i/mHf9oU4v1jnOevpMFH6lIFM3Rmz4DpBx2jctJ5LM8JwrMHR ZNjgIiw== X-Received: from plim9.prod.google.com ([2002:a17:903:3b49:b0:2a0:e956:8aed]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e790:b0:2ae:6457:309a with SMTP id d9443c01a7336-2ae6aaf3d37mr28999085ad.37.1772651476339; Wed, 04 Mar 2026 11:11:16 -0800 (PST) Date: Wed, 4 Mar 2026 11:11:14 -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: Jim Mattson Cc: 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 , Yosry Ahmed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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_vcpu *= vcpu, > > if (is_guest_mode(vcpu)) { > > kvm_state.hdr.svm.vmcb_pa =3D svm->nested.vmcb12_gpa; > > if (nested_npt_enabled(svm)) { > > - kvm_state.hdr.svm.flags |=3D KVM_STATE_SVM_VALI= D_GPAT; > > + kvm_state->flags |=3D KVM_STATE_NESTED_GPAT_VAL= ID; > > kvm_state.hdr.svm.gpat =3D svm->vmcb->save.g_pa= t; > > } > > kvm_state.size +=3D 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; >=20 > 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 restrictin= g the set of valid flags. I.e. VMX's omission of checks on unknown flags is a fe= ature, not a bug. Chatted with Jim offlist, and he pointed out that KVM's standard way to dea= l with this is to make setting the flag opt-in, e.g. KVM_CAP_X86_TRIPLE_FAULT_EVEN= T and KVM_CAP_EXCEPTION_PAYLOAD. As much as I want to retroactively change KVM's documentation to state doin= g KVM_SET_NESTED_STATE with data that didn't come from KVM_GET_NESTED_STATE i= s unsupported, that feels too restrictive and could really bite us in the fut= ure. And it doesn't help if there's already userspace that's putting garbage int= o 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.= :-(