Received-SPF: pass (google.com: domain of linux-kernel+bounces-213790-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: "Li, Xin3" <xin3.li@intel.com>
To: Sean Christopherson <seanjc@google.com>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-doc@vger.kernel.org"
	<linux-doc@vger.kernel.org>, "linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>, "pbonzini@redhat.com"
	<pbonzini@redhat.com>, "corbet@lwn.net" <corbet@lwn.net>,
	"tglx@linutronix.de" <tglx@linutronix.de>, "mingo@redhat.com"
	<mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, "x86@kernel.org"
	<x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>, "shuah@kernel.org"
	<shuah@kernel.org>, "vkuznets@redhat.com" <vkuznets@redhat.com>,
	"peterz@infradead.org" <peterz@infradead.org>, "Shankar, Ravi V"
	<ravi.v.shankar@intel.com>, "xin@zytor.com" <xin@zytor.com>
Subject: RE: [PATCH v2 12/25] KVM: VMX: Handle FRED event data
Thread-Topic: [PATCH v2 12/25] KVM: VMX: Handle FRED event data
Thread-Index: AQHaWfA7ZVshGt6l4U6e8iRthcdnlLHGsbqAgAANdMA=
Date: Thu, 13 Jun 2024 18:02:56 +0000
Message-ID: <SA1PR11MB673412E7813B659F16284B74A8C12@SA1PR11MB6734.namprd11.prod.outlook.com>
References: <20240207172646.3981-1-xin3.li@intel.com>
 <20240207172646.3981-13-xin3.li@intel.com> <ZmslBVWkRHAjIXrE@google.com>
In-Reply-To: <ZmslBVWkRHAjIXrE@google.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kAMvL502CkZ398Xe4sYBCjNZr0jFk+KtOz9qWtlix9mydV0NdeIvarz8cPEn?=
 =?us-ascii?Q?w9zF61FqpZREYzc035aY33mga2E6vxMi62vX6IyED4Lkcmg5rbsaLSa1QUff?=
 =?us-ascii?Q?qAZOYyNGpzh9R8YaemDE6l+ghMhoiqQmhFhu9lJ89Ri+FgQS44JeYihCpNb8?=
 =?us-ascii?Q?YncI5kOqkJe6PFtCCYHF5Ieo9LV/mYaFV3bnuMZLID1DUlfLZUKjUXIc9VZ+?=
 =?us-ascii?Q?U5PI0VE0TBialoOj6mCEnZyTY9jsfUOMo0DXRA7oNnwlKGDmcZOKZVX+EMhA?=
 =?us-ascii?Q?cMD8wzr17giV+syVrsW6XHyzOd5EVBsHAtiYFTHHApMuf0JdcrqMuk+7GgSA?=
 =?us-ascii?Q?8fU9GYBjvJjl/oQf1HsR89aMEEw7n3GwQcYDTbun3rFIzs1x0LY4xAcOwJdw?=
 =?us-ascii?Q?p4w0Erxn7md1JPz7vKRPDuOsyViNrweArhLLvMw8nNN7qCrh+PcYT8bPG0l/?=
 =?us-ascii?Q?lfUe9wYI/DAZX6Z2Qm2LNyMJ97FbAiiEQ5yzIg0jj114FQgNGIePjFwc7zcZ?=
 =?us-ascii?Q?5b2ZGlyDcia6C+cntnUPLZNOIWbRlloXSWqtbwh6c6r7RW5D98hc9lYWa7du?=
 =?us-ascii?Q?arCLq2KfvuTMwRqU5M2eJ5OphnFAZdcVyT6wNTH3XO1sbN0zLmpCJJ5smb9B?=
 =?us-ascii?Q?sppE+AmZbkhQG8pvDjJOCS54fyw0wP2ToTO5m5Bu0/h7oQ1XHXBft82GEdUu?=
 =?us-ascii?Q?1/PhL0r8XP7NS3yEGHcWwOpeW+3ue31AMfvrxRPV+I+ohMegJMj5Xo1EAK12?=
 =?us-ascii?Q?jfJJVhoEkIBDbp6eqhcLLiJzXUSQd4XzkuLylvH1kI7D1xdUczxx6RzWpjXV?=
 =?us-ascii?Q?VWLPxWozkT2g1ZTqIbmVrm/1yzvkM7YKPR2RqXIOCxg5EH//4AP66/OG6Zwy?=
 =?us-ascii?Q?l793yICPjxvm/7OYhxQOkIYk4irDn6MzX6Td7+Oj/a+3w8aOBjDPbe9MH/pY?=
 =?us-ascii?Q?nmm2J35vjH16axALdswpTKxYVVKiqlsiJ6hefLXizaNbgg5Ha/K6E7hwP+pu?=
 =?us-ascii?Q?KHqqTiiGD9DpLw9Z+U8UKwnrDBoxlvZON1tw2kE9kjsxHVbiBWNTx/c19UHx?=
 =?us-ascii?Q?zF6jB3GklK7LzyHIttu6VadL0Holctq/KEfjl0tdJz4i8tb2r8x7D83PNuyr?=
 =?us-ascii?Q?scqB+NkSTxf7FOnInhtXOPJoyv8EWoU5C4xx3g439u9uTlTgrDKfh3NOZj1I?=
 =?us-ascii?Q?HPOMweZmrkbjgNrrdFjCr5RkufIOmUkICLOopBnSd0ZgH99MBMgtjQdhKTou?=
 =?us-ascii?Q?GB5QnqS6Omg9vCKS9MdsTS5l7Pn1EiVyN/FE9e+uLYhn/9iBnp9RC2NR+Lbd?=
 =?us-ascii?Q?lUJxpQ+Bt8AoMoivNyIFdzGpGmVp/3vdghMr5pCSO5G1FnWSOzTr4j29r5Uv?=
 =?us-ascii?Q?K4ukzuFgXpdUhRnAqcSBH5/lLTdRh1EPXMk7spQKkXiFYRJPmUXvCB88oQNb?=
 =?us-ascii?Q?4pJ5OlRGDeLHVK5pzcvj2tSJONOv1xe9Gd8xHJ48+GQQeUzoutmKrcLYUVKd?=
 =?us-ascii?Q?+E2SwPOEpEEH84EmQCLfJBc0AN1AwmNFYXPy6k2yY97DLIDHK31hPJ/9+tNG?=
 =?us-ascii?Q?yruvBp8eoovvUAfAsHM=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6734.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f505d74f-590f-4796-d3f8-08dc8bd30d90
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2024 18:02:56.1614
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6tJuofnfj/Z8lPSyhGTtvB9mcXBUj2hVJo9hiFzUqd8jnR2TeCmkhkBx4I87Od01lN7P6jmZCHVZrcdjyLP2vg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6006
X-OriginatorOrg: intel.com

> On Wed, Feb 07, 2024, Xin Li wrote:
> > @@ -7382,6 +7419,24 @@ static noinstr void vmx_vcpu_enter_exit(struct
> kvm_vcpu *vcpu,
> >
> >  	vmx_disable_fb_clear(vmx);
> >
> > +	/*
> > +	 * %cr2 needs to be saved after a VM exit and restored before a VM
> > +	 * entry in case a VM exit happens immediately after delivery of a
> > +	 * guest #PF but before guest reads %cr2.
> > +	 *
> > +	 * A FRED guest should read its #PF faulting linear address from
> > +	 * the event data field in its FRED stack frame instead of %cr2.
> > +	 * But the FRED 5.0 spec still requires a FRED CPU to update %cr2
> > +	 * in the normal way, thus %cr2 is still updated even for a FRED
> > +	 * guest.
> > +	 *
> > +	 * Note, an NMI could interrupt KVM:
> > +	 *   1) after VM exit but before CR2 is saved.
> > +	 *   2) after CR2 is restored but before VM entry.
> > +	 * And a #PF could happen durng NMI handlng, which overwrites %cr2.
> > +	 * Thus exc_nmi() should save and restore %cr2 upon entering and
> > +	 * before leaving to make sure %cr2 not corrupted.
> > +	 */
>=20
> This is 99.9% noise.  What software does or does not do with respect to C=
R2 is
> completely irrelevant.  The *only* thing that matters is the architectura=
l
> behavior, and architecturally guest CR2 _must_ be up-to-date at all times=
 because
> CR2 accesses cannot be intercepted.  So, just say:
>=20
> 	/*
> 	 * Note, even though FRED delivers the faulting linear address via the
> 	 * event data field on the stack, CR2 is still updated.
> 	 */

Will do!

There is a reason for this comment because it won't be architectural:
https://lore.kernel.org/lkml/c0c7c605-d487-483e-a034-983b76ee1dfa@zytor.com=
/

FRED is designed to atomically save and restore _full_ supervisor/user
context upon event delivery and return.  But unfortunately, KVM still has
to save/restore guest CR2 explicitly due to the issue mentioned above.

Thanks!
    Xin