Received-SPF: pass (google.com: domain of linux-kernel+bounces-122731-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 28 Mar 2024 17:53:03 +0800
From: Chao Gao <chao.gao@intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
CC: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>, "Yamahata, Isaku"
	<isaku.yamahata@intel.com>, "Zhang, Tina" <tina.zhang@intel.com>,
	"seanjc@google.com" <seanjc@google.com>, "Huang, Kai" <kai.huang@intel.com>,
	"sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>, "Chen,
 Bo2" <chen.bo@intel.com>, "sagis@google.com" <sagis@google.com>,
	"isaku.yamahata@linux.intel.com" <isaku.yamahata@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Aktas, Erdem"
	<erdemaktas@google.com>, "isaku.yamahata@gmail.com"
	<isaku.yamahata@gmail.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Yuan, Hang" <hang.yuan@intel.com>, "pbonzini@redhat.com"
	<pbonzini@redhat.com>
Subject: Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages
 for unsupported cases
Message-ID: <ZgU9/61//F17r1nw@chao-email>
References: <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>
 <ZgKt6ljcmnfSbqG/@chao-email>
 <20240326174859.GB2444378@ls.amr.corp.intel.com>
 <481141ba-4bdf-40f3-9c32-585281c7aa6f@intel.com>
 <34ca8222fcfebf1d9b2ceb20e44582176d2cef24.camel@intel.com>
 <873263e8-371a-47a0-bba3-ed28fcc1fac0@intel.com>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <873263e8-371a-47a0-bba3-ed28fcc1fac0@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TmpIUTNTT1BCL091QSsxcFRJWndlSWVVVzVHNmIySk9OT1JhdFhTNVExdVFy?=
 =?utf-8?B?NmxOSVd2TFlTbFM4RDQ3UGFZTW5TdWhYYmFMbHZ5MFFzZFl0YzZYbDRlM3ds?=
 =?utf-8?B?Z3RweXVVR2VXclBDcmExRXJraVJ0bmhPZ21iWFRzcE1DU3AvUHZYRVFtRjlM?=
 =?utf-8?B?T3hHOVJlYUpNdjRudjFHN3YrNi81UE5DM1ZVZkczQjZ3VHcxeFJncXo2Q2g3?=
 =?utf-8?B?N1E0VFVlemltSlpHSkl0MTlienBZQnFyME0vT1MxNXpsQ2k3QTRINnphNXhR?=
 =?utf-8?B?SHJDRUhyQ29PRUQrRnN4Slk1bUdINVlHa3YzQ3duOW43YStCQlRzamk4bVZ5?=
 =?utf-8?B?NVVQYU1Hb1FhdkpOZXU3SGRnZzVHeU80YWhlbHJhK3BpUkgzUWpWTi9QbEdG?=
 =?utf-8?B?NVFzTG9COGhpdGhJTitLUVBXazZtdWJlb3hjR1RQRHBUdEFRUDZDU0dZNnNm?=
 =?utf-8?B?VE5UWkM5N00rYzFudWkxVVdOUmgyVUtnQ1drcytReVFwVjhxSEtUREF0NzQ1?=
 =?utf-8?B?YTRlT3VUZXBzOXJ5OTVwU0gvNndiRG5FcWxSMHNXalF2WllrQmJmT0J5bWFy?=
 =?utf-8?B?YkpwK05ldm9YUUIyUXZJbHBpeEs2czNYTTNxYjhrZm92WmF4dGVFWmxpOHo4?=
 =?utf-8?B?UEEwN2h6NHI2bld6TXhtWmdXNlhaUHVsczZGMVdsL1gxL1pSWlR4WlBKaVJM?=
 =?utf-8?B?RHNCNUQrR0QwTStldVRHVk8rY2I1SUxJU2V5Y1plL2VIandWVHlwaUt6Vk54?=
 =?utf-8?B?d1gyUmFRV2R5WmlTalNjNXJMZEEwNXNjOVZySUVUZG5uMStxMk5iUkZGZXJW?=
 =?utf-8?B?RDF0NE5EVlYrQVhXV0dlSlN0c3Ixcm1yVXBtNm9ZWVlPaTZaWXRHSUloY3M1?=
 =?utf-8?B?VGo2TXo5MzBVZ1J5Sk5PeStORkJ6L2VzKzNmUDU0NVU1WjJIQVZVeGIyL1JE?=
 =?utf-8?B?bkdHZzNwTnJVM0VuNERjang3bXN2L1NyVVF4Q1ZSQk4wcVJZckxsMDdvcWR2?=
 =?utf-8?B?d2JoakRYaTlyRExKa2UvVVBsQlNKcE90TldHZkdkR2U2M1hIcWgwUEwyS2hk?=
 =?utf-8?B?Y1FTbGJUcVZCT1ArZVI5OHdDejBmL2ZCL1BpQTAzR0dxUjNGcG44ZlNIdU5k?=
 =?utf-8?B?bUVQdTBsOGM1ZHFpZ0cvMTczc3NLdE9haWJPbGROM1hCTmRrNjl6MVhwTWF0?=
 =?utf-8?B?M0wwR1NQM0RBOEZSak1zdjg1eUxFNVdpRnRveGo4aFpsZHFGc2NMbW9aRkxo?=
 =?utf-8?B?cE1GcnpmVlRvYml5aUp5NVZiN2JyRi9xOFN2NWVjNjBpOVdQREZqbnRDNkpp?=
 =?utf-8?B?K0JYcUpVc0tXd1kzM0lLQ2lHenMyWG5NN2ZhdkdtTFhHQjZKQ0F6Nm0ycUc3?=
 =?utf-8?B?dHBsOVh2czhLck1yY1JZN0lLSWlPaGo0U2ZWQm55b1hjeW9OaGdTS0lnTEQ1?=
 =?utf-8?B?QVBjVkxFV1g1UzFKcTFGV095MlVITWJFRm5YS3BLTmJad3l0ekVFcitONFhs?=
 =?utf-8?B?Q0lHMkJ2NVQzZUNwNnY2NTF3eUZLTkhUVGRXbEx4NVhuQzJScTlVRklxT1FN?=
 =?utf-8?B?ejVNYnROOCtOQXNZWHZTeHFOb243cFhWb2FOZUNLTUR0UnhCYlVTSVEySElr?=
 =?utf-8?B?eFE3YWhkSXhJaUYzaGZwZHB3N0hTSFN0US9Jd1Vscm50eStab0UrOExzam80?=
 =?utf-8?B?VFhHV3lmMkw1Q3A2bUl3RUJuS01wYS8rVnEyZU9KV2tXaHJNU0JqSEw1c2Er?=
 =?utf-8?B?cVBqMWFrZTVYTTV6TVdPMDQyQXIvUWdxU2krbjdxMGpkUk9xUkdBdm1GdHl3?=
 =?utf-8?B?MDRGaW5IRUltazBxWHFxUE10WC9pZ1pzYjBDVklzaUpZd0tWeVBPeHRqMFJN?=
 =?utf-8?B?R3FzcXdBMGxJbjNVeS9ZSzh6bkN1R1ZKaDRiakhTTE9NOTZaUWlGY3JFYnVM?=
 =?utf-8?B?dHNmS2IwNDZRaG53VGhBZUsxMXh3eDZGbUthcmI5NlZrKzNHNzJaQjBKR2xT?=
 =?utf-8?B?SFF2OXNIVy8vMFlYM09YRHdSNHA3aHc2UWZkRnU1N2M0cldhZGN6VEJKK3BI?=
 =?utf-8?B?dkRLZVErWEwyN3hRZnN3d2FsQmtMRVRmL2ZGcFNFNDNWRTVZRkpzT0UzWDVh?=
 =?utf-8?Q?fkKSJvUjNAQVqSgnM6l0+aum1?=
X-MS-Exchange-CrossTenant-Network-Message-Id: aace672d-bcc8-4d53-f3f5-08dc4f0ce286
X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB8660.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 09:53:14.1919
 (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: OOJ4Qr52aXTktmEoUDWpf69x6dKk16W6Z7S/HjGLEzKbfoVxX7UVPQQ+dpziEZl1XhcI73/BA4KWGsA8rZ9pFg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB8336
X-OriginatorOrg: intel.com

On Thu, Mar 28, 2024 at 08:06:53AM +0800, Xiaoyao Li wrote:
>On 3/28/2024 1:36 AM, Edgecombe, Rick P wrote:
>> On Wed, 2024-03-27 at 10:54 +0800, Xiaoyao Li wrote:
>> > > > 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.
>
>TDX spec states that
>
>  18.2.1.4.1 Memory Type for Private and Opaque Access
>
>  The memory type for private and opaque access semantics, which use a
>  private HKID, is WB.
>
>  18.2.1.4.2 Memory Type for Shared Accesses
>
>  Intel SDM, Vol. 3, 28.2.7.2 Memory Type Used for Translated Guest-
>  Physical Addresses
>
>  The memory type for shared access semantics, which use a shared HKID,
>  is determined as described below. Note that this is different from the
>  way memory type is determined by the hardware during non-root mode
>  operation. Rather, it is a best-effort approximation that is designed
>  to still allow the host VMM some control over memory type.
>    • For shared access during host-side (SEAMCALL) flows, the memory
>      type is determined by MTRRs.
>    • For shared access during guest-side flows (VM exit from the guest
>      TD), the memory type is determined by a combination of the Shared
>      EPT and MTRRs.
>      o If the memory type determined during Shared EPT walk is WB, then
>        the effective memory type for the access is determined by MTRRs.
>      o Else, the effective memory type for the access is UC.
>
>My understanding is that guest MTRR doesn't affect the memory type for
>private memory. So we don't need to zap private memory mappings.

This isn't related to the discussion. IIUC, this is the memory type used
by TDX module code to access shared/private memory.

I didn't suggest zapping private memory. It is my understanding about what
we will end up with, if KVM relies on QEMU to filter MTRR MSRs but somehow
QEMU fails to do that.