Received-SPF: pass (google.com: domain of linux-kernel+bounces-118855-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 26 Mar 2024 19:13:46 +0800
From: Chao Gao <chao.gao@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
CC: "Yamahata, Isaku" <isaku.yamahata@intel.com>, "Zhang, Tina"
	<tina.zhang@intel.com>, "isaku.yamahata@linux.intel.com"
	<isaku.yamahata@linux.intel.com>, "seanjc@google.com" <seanjc@google.com>,
	"Huang, Kai" <kai.huang@intel.com>, "Chen, Bo2" <chen.bo@intel.com>,
	"sagis@google.com" <sagis@google.com>, "isaku.yamahata@gmail.com"
	<isaku.yamahata@gmail.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "Aktas, Erdem" <erdemaktas@google.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com"
	<pbonzini@redhat.com>, "Yuan, Hang" <hang.yuan@intel.com>,
	"sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>
Subject: Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages
 for unsupported cases
Message-ID: <ZgKt6ljcmnfSbqG/@chao-email>
References: <20240321225910.GU1994522@ls.amr.corp.intel.com>
 <96fcb59cd53ece2c0d269f39c424d087876b3c73.camel@intel.com>
 <20240325190525.GG2357401@ls.amr.corp.intel.com>
 <5917c0ee26cf2bb82a4ff14d35e46c219b40a13f.camel@intel.com>
 <20240325221836.GO2357401@ls.amr.corp.intel.com>
 <20240325231058.GP2357401@ls.amr.corp.intel.com>
 <edcfc04cf358e6f885f65d881ef2f2165e059d7e.camel@intel.com>
 <20240325233528.GQ2357401@ls.amr.corp.intel.com>
 <ZgIzvHKobT2K8LZb@chao-email>
 <20db87741e356e22a72fadeda8ab982260f26705.camel@intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20db87741e356e22a72fadeda8ab982260f26705.camel@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?QuwmKZ4foh6nxHICSskApc3CQUDaGxqLJdhFJonWLJCuBjMCbAC0wtp9Pw?=
 =?iso-8859-1?Q?I+OGqg5lPjJ1tNpW181pk6pgqToZ5P87NAVhGHkt4OkDfvcs+kQ4/+ZR2R?=
 =?iso-8859-1?Q?XBC6LQ7l6IHetKrYQSlsrlzVXQXWFITTQY1yBgZd5Q541fuqBgZFpiFryj?=
 =?iso-8859-1?Q?LHP0hwMkWpqtT7H1MFujrUhTLUNJO/sm4jHAGphx/vTjxIPgwh71vbSa8R?=
 =?iso-8859-1?Q?uyVs9errJOij8FcwHGoxyImuVp72wOZ1D9gMRwmIuUdFQcsxGRB0VAJQSF?=
 =?iso-8859-1?Q?6KZVx1DxDVh01yGBEOFN/eG+Xdh/S2y5oE/R3Q38v0bbRGZSyws7PxujPe?=
 =?iso-8859-1?Q?ev2O8CdsD0PAoojb1xanUi5mTyPTyNr5Ela1JnSYjyOW1FyooYoYIym1rU?=
 =?iso-8859-1?Q?o5Cg8tl07/yEcLLbF989sTr7yUpjPG7lAfZuVxM0NGD1cJ4EG2d6AM8fwe?=
 =?iso-8859-1?Q?ltBOit9/RPYzVWsgNNvwK1BW126cvgOBaj9bxpP2LD8xiiBpfjyyFxWQl8?=
 =?iso-8859-1?Q?CshvdCZi5CtKHPRGaZTlmNlBGBnHT43+swbWdNJSsn0hZ3i4HQX9agZr7P?=
 =?iso-8859-1?Q?/OMV9RUzAowjHLvuq7z1bTmqPJjenlRN0pGl6jFWXIxpl1MVzizq2IejGS?=
 =?iso-8859-1?Q?2JC8dIzLndpW2NdfCSho7ux/HTJoIUNlMowceTZFiNKwOdpF4nMZYBgcKZ?=
 =?iso-8859-1?Q?zWjBks5f+ssojtSzzHpzlf+A2iOAZNM9f9h24h1Fci50VS2Ufeklp9IeAH?=
 =?iso-8859-1?Q?w+ZkGSqNcrFNpSf8QLmxXmdpJ/viek/slwCgjC9hj21bN0Br+aY5y7kkYh?=
 =?iso-8859-1?Q?rRt1ZLHz8qOPdC7JA6oaXqZ2D+pGB2pbsaYBJPFLtjCRAkNGhDzVlhpq6U?=
 =?iso-8859-1?Q?4n127Ed/cq97MMkKFp6R3AUV4gBjyaopgxLVL3DXQAGfhdnXXK/xuNGDD+?=
 =?iso-8859-1?Q?JKvWuxFHv5Q2lhysy2ZBH4ViUPczJ+j75k07IbNBTiIwH92DeQCGROWp6i?=
 =?iso-8859-1?Q?4xosVjzEKPe/ihS9O/ql78XSohIijU4qGIsXEowAnUtDEV/d0L6KELRUNR?=
 =?iso-8859-1?Q?Teaoc7hQJAyT//DQrwh8xNF8z36IKFilLRtfLtVFS8PQ2IojaPRPUQp59S?=
 =?iso-8859-1?Q?oXlzw7fAt8XQm30906bh8Lb7rFP1BYFyGEJNsPAl1Fhfsq45Ux5FzVueLW?=
 =?iso-8859-1?Q?5BwEJMIrMchy1kB6jx+heYkHhE9Brv1Ce49Pzobpt6nlgJFHcVwwMUuTdm?=
 =?iso-8859-1?Q?ZJXBoyh5N2Gk3pL6ppftO0ZCZFwsS1B1Cpf/GTmDKt4al/2E94GmMFH7sV?=
 =?iso-8859-1?Q?dNRN0CouhqVPtKiaUTKbClaJPCksk/E9qrgxCFowZmF6PtR432j6A6Vv4C?=
 =?iso-8859-1?Q?fs3F0l1oH2F7pJn2SDu9Vec+Nk7S7Ws0WwAOZE8TUQ6cuGG6Aqs06CUHp+?=
 =?iso-8859-1?Q?ysJtvFMShw791WCf0xJ75Q4VLs+wB6sDB0+Qxmgt4+vC3zSihs8J6DA35D?=
 =?iso-8859-1?Q?cM6p08ja58G5l3Q+QcaF67WGBP8BJQnfzxQ6nLYmTvJMq/mOoO7DU//Ixd?=
 =?iso-8859-1?Q?57nJdTXm3vlGBaoahGH09B48iuFUip8BRAJLfChOZMhbHzg4b8IVbADg5v?=
 =?iso-8859-1?Q?HkBQN+S4MlhcnvHFVdNYtEeZyMxJVzpanj?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e5a9894a-2d78-4deb-6f6b-08dc4d85d3ec
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB8665.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 11:13:56.2596
 (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: 8q5yVuvAbj8FYbw3P1upLMj2HCw5S44cMRM/XvcH4An46AeV+317MZ0UiahS7BTCx9WrcSxFW7aM7reg7MwUMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB8004
X-OriginatorOrg: intel.com

On Tue, Mar 26, 2024 at 10:42:36AM +0800, Edgecombe, Rick P wrote:
>On Tue, 2024-03-26 at 10:32 +0800, Chao Gao wrote:
>> > > > Something like this for "112/130 KVM: TDX: Handle TDX PV rdmsr/wrmsr hypercall"
>> > > > Compile only tested at this point.
>> > > 
>> > > Seems reasonable to me. Does QEMU configure a special set of MSRs to filter for TDX currently?
>> > 
>> > No for TDX at the moment.? We need to add such logic.
>> 
>> What if QEMU doesn't configure the set of MSRs to filter? In this case, KVM
>> still needs to handle the MSR accesses.
>
>Do you see a problem for the kernel? I think if any issues are limited to only the guest, then we
>should count on userspace to configure the msr list.

How can QEMU handle MTRR MSR accesses if KVM exits to QEMU? I am not sure if
QEMU needs to do a lot of work to virtualize MTRR.

If QEMU doesn't configure the msr filter list correctly, KVM has to handle
guest's MTRR MSR accesses. In my understanding, the suggestion is KVM zap
private memory mappings. But guests won't accept memory again because no one
currently requests guests to do this after writes to MTRR MSRs. In this case,
guests may access unaccepted memory, causing infinite EPT violation loop
(assume SEPT_VE_DISABLE is set). This won't impact other guests/workloads on
the host. But I think it would be better if we can avoid wasting CPU resource
on the useless EPT violation loop.

>
>Today if the MSR access is not allowed by the filter, or the MSR access otherwise fails, an error is
>returned to the guest. I think Isaku's proposal is to return to userspace if the filter list fails,
>and return an error to the guest if the access otherwise fails. So the accessible MSRs are the same.
>It's just change in how error is reported.