Received-SPF: pass (google.com: domain of linux-kernel+bounces-180492-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <571be50a-d7a9-4d7b-98f8-0d97dafce14d@intel.com>
Date: Thu, 16 May 2024 11:36:04 +1200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/16] KVM: x86/mmu: Introduce a slot flag to zap only
 slot leafs on slot deletion
To: Sean Christopherson <seanjc@google.com>
CC: Rick P Edgecombe <rick.p.edgecombe@intel.com>, "dmatlack@google.com"
	<dmatlack@google.com>, "sagis@google.com" <sagis@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Yan Y Zhao
	<yan.y.zhao@intel.com>, Erdem Aktas <erdemaktas@google.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com"
	<pbonzini@redhat.com>, "isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>
References: <20240515005952.3410568-1-rick.p.edgecombe@intel.com>
 <20240515005952.3410568-3-rick.p.edgecombe@intel.com>
 <b89385e5c7f4c3e5bc97045ec909455c33652fb1.camel@intel.com>
 <ZkUIMKxhhYbrvS8I@google.com>
 <1257b7b43472fad6287b648ec96fc27a89766eb9.camel@intel.com>
 <ZkUVcjYhgVpVcGAV@google.com>
 <ac5cab4a25d3a1e022a6a1892e59e670e5fff560.camel@intel.com>
 <ZkU7dl3BDXpwYwza@google.com>
 <175989e7-2275-4775-9ad8-65c4134184dd@intel.com>
 <ZkVDIkgj3lWKymfR@google.com>
Content-Language: en-US
From: "Huang, Kai" <kai.huang@intel.com>
In-Reply-To: <ZkVDIkgj3lWKymfR@google.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K0xSZXFyR3NoaWpwUnFwQitQTTdzVUdhV2VTZG9PUjZhK0dZdDNCaGFBRm44?=
 =?utf-8?B?T3BRcDJrKzhudzQ1NDlkUlppVXVTMjZwRno1M2ZJQllRWDk4b0gzY0R0L1lH?=
 =?utf-8?B?Q1N6VXo3Ny9wWDRqcitDdU9Oc1B5R3RhUE4rM1hoMHdaSWYwSEl5cnlzL20v?=
 =?utf-8?B?WjlTbldheXJEOVJlMXZyRXNKRmhySzhmZVIxdWkxeWNDbXlNUFFCRmtkS2Yy?=
 =?utf-8?B?Q1d1dW9JYlJ4T2M5Z1lYVGpkK0c1emdFMEcvdlA3ZUgzejRIVDRWSVd4eUdK?=
 =?utf-8?B?dDRoc0lMY0RrOXM5YWhxZ0xRNWF4UDVGeEsvWjYrMGZPOUpQUVhEVUdZVWdY?=
 =?utf-8?B?bUt5aFN6RDdqWUovYlJQK2d2OGF3eUZmQTBYdUtheUdNaTlmQnR3aVdjek52?=
 =?utf-8?B?U3pTVjkrM2R3VmpYc1c5c29USGVaaDluRnJzSStrTVpld0tENTExMkJDemow?=
 =?utf-8?B?UG9sQXo1SkI5SGU1MnIyQ3BKTXFPRUN2VmpKUVh6Z2hrY0cvQ0NmKzV1ekpz?=
 =?utf-8?B?SG9lRXVibXNlS1gwV1owUlNVTXhSZGptaklBeGR5bXVmRklnbzdxTHdZN3By?=
 =?utf-8?B?MmMwa0c3NzlyYjJUdW1mc2RCYlluY25zRmhvZjNmVTBZVnA3dVF1a2gvTjcz?=
 =?utf-8?B?SWZyVzNDa0xic05iOW1Va2lsNzlJeDlwdnpENHNZWFg0Y01jdW8zR2VRVUt2?=
 =?utf-8?B?YWxkRkNQNkZuUUtEdzNDdkQyOGdvRTY3WEdYZjBMMG4veXphZ0hMbTMzdlFC?=
 =?utf-8?B?L2liZWlNZ21kcG9wR1lEb3JEZTVTbTU3TkFKVHlWQ3VTbUx6dXR2MURZT1ZT?=
 =?utf-8?B?OTdob1VIb3R3R2JxaEY1cnNud1VWb1k0elVQblZCb2tubkxpUlBoUVhudEt6?=
 =?utf-8?B?ekd3T1dOZ0pQaFV1SFNIVUMrMzdzazBuVllIdnVQYnBxWEZJRExDNGgxeFJR?=
 =?utf-8?B?TmplR3NhanFaN2dsaE9ScTlZaXJRWmdWTDlSRkU3RU5pZ3hxdVlwKzBKU09C?=
 =?utf-8?B?b3F5czhGM05qVnhiVksrVW9kZlQ2UWZ3R3ZiL3luK05PdDg0YzRJSWtLcWRH?=
 =?utf-8?B?ZTljZHhGOWlsUzcyMkRnWTIwZ0VWbkFVbzJSQm5Yd1RyU2I0SlEwdWY0amls?=
 =?utf-8?B?bk4zZkc3Nm8xNXFxdzFEWXh4aUpIR1g0VDZ5alZjdTVweFFQTklLTGJtaGQx?=
 =?utf-8?B?dEtGNUxTZmRoZ1JoWXVIcWZwQ21FeDlhMWl2SU5QZVBndTJGY1JyT0thZkpk?=
 =?utf-8?B?dkdwRTZFUkM4UWRKQUkyT3M3aVFJdEs2VFpld2dxbjlSL0FnMVBQT0lvdTRH?=
 =?utf-8?B?Z2gydkk1aWhVOE9Hd0FZSEV5YjhEZkxPMTArUEhPNEtTZFM3Q01jZStrblB0?=
 =?utf-8?B?ZFV3SXlUcjcydFJVNFJYakFWaG9aRzR5cWdJQ2F5ZFVsTTVBL0RvdDJ2ZVV1?=
 =?utf-8?B?UldnMjhpL05lOVpEMldxQ0t4SmZpYW1NQ2xCeWhGUEE1NVpZd1JGenZGT3E2?=
 =?utf-8?B?c1BkRjZUbFVWTFhYcXgrQlQ5cUpBbE42d3pPQ0IxU2J6d01aNDdFVERNLzdE?=
 =?utf-8?B?OTZ0ODZHMWxlMVRrb0djN0ZXNHJURkJIMERyK1dob0JFdXQvc0FaVCtVam9I?=
 =?utf-8?B?M09kZWJmZzlmTUVMZktRVzBvQlBFWGhtK0pFVjFEKzlVc1lWNmNWRXNJSVVF?=
 =?utf-8?B?b3d4cURiaE1FaU1DcmplM0N5M3c2WWJnRkVYR1ltWXRuMjB0L3pIYU9uUzRw?=
 =?utf-8?B?OW5UVXlCMU9HaGU5YmhyR2pianA4YnoyUWhMWHg0aEZyRUJhYWJrRlpBSi9y?=
 =?utf-8?B?Sk5odEE1YlJ0ZU1OL0srQk92N1R2UGsvTHphcmd0RzFmNktvQks0eFd3dHlp?=
 =?utf-8?B?bDV2WDFndW1nQ2YzL3BCSzVnbTN5UFhXRFRBR1VHa2xOUnFaOGJuNUZybG5D?=
 =?utf-8?B?RHJNSHNBSWRsM2FPYVV6cERxL05LZzVvN1VJQTJOV2dUaXpVMTYrSGRuQ3Ny?=
 =?utf-8?B?ODZJODhjeVMzM1JyV09Qb2tJN200WXh4bzJHY0piSGNGOXc0cnNteTdPVWps?=
 =?utf-8?B?QlB6R1d1ZTE3R2NsdmlvZUxpQzR4QXJtTjlXTGNpWlVWQlVDVHBxc2lvTk1Z?=
 =?utf-8?Q?rjXmsm9ajbArMscdcDytLLRR4?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 49cf02a0-ceb4-4128-dd7c-08dc7537ce96
X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5978.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2024 23:36:13.1221
 (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: WugoA3aiqRaO/tPYiooqnsMtt3y5yj4+CSOdt97k/DSBjphwBNi2whEphfNuqfYtFGP68XVr4yhY5DJ8SiIj3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7562
X-OriginatorOrg: intel.com


On 16/05/2024 11:20 am, Sean Christopherson wrote:
> On Thu, May 16, 2024, Kai Huang wrote:
>>>> You had said up the thread, why not opt all non-normal VMs into the new
>>>> behavior. It will work great for TDX. But why do SEV and others want this
>>>> automatically?
>>>
>>> Because I want flexibility in KVM, i.e. I want to take the opportunity to try and
>>> break away from KVM's godawful ABI.  It might be a pipe dream, as keying off the
>>> VM type obviously has similar risks to giving userspace a memslot flag.  The one
>>> sliver of hope is that the VM types really are quite new (though less so for SEV
>>> and SEV-ES), whereas a memslot flag would be easily applied to existing VMs.
>>
>> Btw, does the "zap-leaf-only" approach always have better performance,
>> assuming we have to hold MMU write lock for that?
> 
> I highly doubt it, especially given how much the TDP MMU can now do with mmu_lock
> held for read.
> 
>> Consider a huge memslot being deleted/moved.
>>
>> If we can always have a better performance for "zap-leaf-only", then instead
>> of letting userspace to opt-in this feature, we perhaps can do the opposite:
>>
>> We always do the "zap-leaf-only" in KVM, but add a quirk for the VMs that
>> userspace know can have such bug and apply this quirk.
> 
> Hmm, a quirk isn't a bad idea.  It suffers the same problems as a memslot flag,
> i.e. who knows when it's safe to disable the quirk, but I would hope userspace
> would be much, much cautious about disabling a quirk that comes with a massive
> disclaimer.
> 
> Though I suspect Paolo will shoot this down too ;-)

The quirk only works based on the assumption that userspace _exactly_ 
knows what kinda VMs will have this bug.

But as mentioned above, the first step is we need to convince ourselves 
that doing "zap-leaf-only" by default is the right thing to do.

:-)