Received-SPF: pass (google.com: domain of linux-kernel+bounces-99715-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <5ee34382-b45b-2069-ea33-ef58acacaa79@oracle.com>
Date: Mon, 11 Mar 2024 18:10:50 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH 1/5] KVM: x86: Remove VMX support for virtualizing guest
 MTRR memtypes
To: Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Josh Triplett <josh@joshtriplett.org>
Cc: kvm@vger.kernel.org, rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
        Kevin Tian <kevin.tian@intel.com>, Yan Zhao <yan.y.zhao@intel.com>,
        Yiwei Zhang <zzyiwei@google.com>
References: <20240309010929.1403984-1-seanjc@google.com>
 <20240309010929.1403984-2-seanjc@google.com>
Content-Language: en-US
From: Dongli Zhang <dongli.zhang@oracle.com>
In-Reply-To: <20240309010929.1403984-2-seanjc@google.com>
Content-Type: text/plain; charset=UTF-8
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?NTRnalZUQzhmTG00OGVpWmo1Y29JbmwzaStjSy9LTXh3SDI3ZzRta1RsSWJS?=
 =?utf-8?B?akZKUi9wMzl0dzQxKy9HOStIZ29PbnZYbVRvZEJkakpaRThhYnhndlhTNDFp?=
 =?utf-8?B?dW8rd1d4R0YwaloreXNXRFBNTHNKcTFRc2Y0QVk2b0U3UU55L042TVFjK1Vh?=
 =?utf-8?B?cWpoYW1aR3FCdDErZUdiVUZ0ZmdSSnpBdjJhNXRDWVJCVWkzaENyUFZmVmZl?=
 =?utf-8?B?eEFrQWdzQ3cvMi8zOFFjV016RlB4ci8zTWI2U1NsdEw0VFBZU0xrQVpyM0o2?=
 =?utf-8?B?TCtNbWFlNlRhKzdtZWxnUEhvbHBzb3JNMG5HM0JhVFRoRVpZdGF0aE85WTNn?=
 =?utf-8?B?ZTJuZ1VmM0FFWmxITWkzelFuamxrbEJ1OEVYWXUva2NjNGNUOU53VnZQSlhH?=
 =?utf-8?B?bEFISDAycmtDaTlWMjJ0MXcxVGFHRjNQUmRrV0V4UVYwQUNjanMxL2xPS3Ro?=
 =?utf-8?B?MEJ1bXZZTEUvKzBqN0J3ejg2dHpCaWcrRkhBYlBxdnVLMGZxU0gwRnluSFIx?=
 =?utf-8?B?SDFqVTN3SkN4eHZzWnJxQTFCaEQwR3ZoeFdqNFhTd2NCK3ZNTVBkeGlxUFZJ?=
 =?utf-8?B?d2FsdGdWZU5qSVZaMGI1RGk4QTRRaXBTZktUb01XMnFvSUwzblkwRzMyVDZX?=
 =?utf-8?B?VzFUQnNFSEoyd3ZVbjhoV2dDZVRzWnF0ek10bjFGemoyTEhreGJISk1MN2Rh?=
 =?utf-8?B?U2lSWmovZUxZMFRVYjEraXlxSFhyZ1VaWlpWa1BEQ1QvREM5WnAvZGhwZy8y?=
 =?utf-8?B?Q21BVXpxRXdJd25KQWg1Q2ZkNEcvMVFCQnpDZFFKNUNjK0M5K3VBUmw4ZWlp?=
 =?utf-8?B?WFFaeU5BeDVoOFFCRFFvU2NqaXZ5dEx5YmppbzRseTg5ZjZPbDZURW9PQ1hx?=
 =?utf-8?B?K3F2NTB6VVViOHo5QU5mSDltTCtZUlRJMlBpb3d0VEswWWg0ZlZ3dUxYN1pI?=
 =?utf-8?B?Y3lFajRoZmsvaERTdXpmMzBSWEYxVWRzTXVLSXhRd25WNzd3NDlqR3pzbitT?=
 =?utf-8?B?eW9hQ2Zrd0cxRFFKYjZKWnZuMVd2a2NTcCtrYmJQTzhDQjUzY0M4NUNhTjl1?=
 =?utf-8?B?VE0wQlhLOStuUjVUYVFZdWNxWFNkSWRHa1JRejNsakZIUEI4TjhWRXBYbG5v?=
 =?utf-8?B?MTdlYXJ6ZWF5WGliSGVCWDVDbHducHpPM0huSE5iaENEVnZKaHNUR05rQUNh?=
 =?utf-8?B?VTZDY3kxeWVESldJRmZLSG1tNXg5cW45Z0E1ZjJyYW4xeHdoRTBPZ3FkLzlD?=
 =?utf-8?B?b3daV1ZnYjVCc3VOZ0lwV0UxZnkvMlJaUlQraVoxQ0JpUHhxUXNuckhic040?=
 =?utf-8?B?azRvdUlNN1dkUGJiSG83eHNweGYxUitLNnZ4NXVTVkNEZytRa3lxbk1zclVC?=
 =?utf-8?B?NnBoWFRha1gvdkVTUlVUdGIvTnJ2V3hmT09oVW5FcGYyRFl2RjMxTFVOUmp3?=
 =?utf-8?B?VTRKYkR3WUk4ZUFXNkFibGpTL0FnZ3U3QWRHK0xBVTI4MUZDNDAzWWJ3elAw?=
 =?utf-8?B?YWREdnFsWVArSWhKNDZRK0lvZEl3U0N1aVB2QWpwdkFOVVdKRjZSanFacFdv?=
 =?utf-8?B?S2JKTURTNWZSN3pXV1IxSTc2RXNEbThseEFyVUtSRDhiY1p2TzE0QjlHb09l?=
 =?utf-8?B?VWx3WUwyUXdDVXNJVUppbkVnMG85RmxyTGt3emwwL29ic3pXUHhLWUtrK2dD?=
 =?utf-8?B?Q2Zyd0VjSERXNUQzNXEyMTc3eHp4eVc2WW5waFNERzMxQlYxUDR4MGpFK2xZ?=
 =?utf-8?B?L3pSTm0wbWhzWmZ0azI4ejlHeEh2ejk3dEMyYUxKelBSL2huQktKQStsME5Y?=
 =?utf-8?B?ZHNDZEg4eW9sWDRxMlY2a0ZpelFScjVVekt0QThZaHloS3Jvemd0Q0F5bndW?=
 =?utf-8?B?YVZod01acGNHREQrSTdSOE1ZY0dMMXlpZGtwbTEyTzBnWjE1OWJTUGcyUUN3?=
 =?utf-8?B?cFJ3NUVyTllVL3hNSEd4Yyttb2xRdnNtaDBTVlpURjdCUVJtZFkrai9QZkkx?=
 =?utf-8?B?d3d6M25adHhOaHU2bWVZTCtoSVh5RlhpS05Xa2xiWkpaQnBnTWlDRlIwYUJa?=
 =?utf-8?B?OEdHMnZxQ0pLTVUzMmJmbVJzVEdzK0x4TlA3UUxDTEJ6ckdCMVVXSUVjeVFP?=
 =?utf-8?Q?zWYgWL7jCmpUjhEQc9PwclqZg?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	4H01ORUno2I02Zqpd8BiZ/IcO6yY7uhlJthfZNi1XclcVnIbJERGfgy3RKiVuM3Y647Djc5/+xVHuoQzU3imG3AQfK2SrwAZN4L42ymr2TXcnlUz2FwEd/hKOUB5V/TyjqF19UeYtbB5Ri6WhXwC55va1+Y17j3cHTprNnt1rcPkNYwwio//zEqdcaZnpB3n6og71Wanvq+mp0m1gIxpLNuA2QSlD5tV3H5g05SzgMKL6v8zhEjEemgvKThNlTnLGJTfzNw2Q3sV2uCcZL51weYI+njR/gyDki8Wbo2HDqCJ93hPzjCG/W/oJBHeuYtbMYcGIEY4eeMdB/eHbWDy4FQcQkYiFRFgqIP8a0luFLoODusePld5T4tKZmnn6Ky6p2DWewKBlvMOYTa733ShECPVbMXjlDQOYEDLISSOFtkZeviv3wMXNqDPnf5BHdF72g7QGVyYkPWlZ/f6qg0vOuaxC943hauAVdbCJ3qA1Iw94/5G3Xxj2svBi3hB06ha5zSfw0ncUaz5iRVZIZediX3EEr4s8Wnts5mEj8oHlzOCKGW+xHnFEhEjMKn0AI+WQJS061+45NUgP3i3L1/xt9Nn8gLcONqwqJaWozDnhwM=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4cdf3606-1ba5-4f57-89f4-08dc42314425
X-MS-Exchange-CrossTenant-AuthSource: BN7PR10MB2659.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 01:10:54.4797
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Ot4exYAeXGH1rOFI02rzfPI7lh0491HjNnRuyxW46UPktSmu4LhuwKtnW2ICj+eEn+aMmQE4Wrk3KMWDMmbuzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB6073
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-11_13,2024-03-11_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0
 mlxlogscore=999 bulkscore=0 phishscore=0 malwarescore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2403120007
X-Proofpoint-GUID: sr7AqKKxtLsARFzJgSNaVCrnvPZswawv
X-Proofpoint-ORIG-GUID: sr7AqKKxtLsARFzJgSNaVCrnvPZswawv


On 3/8/24 17:09, Sean Christopherson wrote:
> Remove KVM's support for virtualizing guest MTRR memtypes, as full MTRR
> adds no value, negatively impacts guest performance, and is a maintenance
> burden due to it's complexity and oddities.
> 
> KVM's approach to virtualizating MTRRs make no sense, at all.  KVM *only*
> honors guest MTRR memtypes if EPT is enabled *and* the guest has a device
> that may perform non-coherent DMA access.  From a hardware virtualization
> perspective of guest MTRRs, there is _nothing_ special about EPT.  Legacy
> shadowing paging doesn't magically account for guest MTRRs, nor does NPT.

[snip]

>  
> -bool __kvm_mmu_honors_guest_mtrrs(bool vm_has_noncoherent_dma)
> +bool kvm_mmu_may_ignore_guest_pat(void)
>  {
>  	/*
> -	 * If host MTRRs are ignored (shadow_memtype_mask is non-zero), and the
> -	 * VM has non-coherent DMA (DMA doesn't snoop CPU caches), KVM's ABI is
> -	 * to honor the memtype from the guest's MTRRs so that guest accesses
> -	 * to memory that is DMA'd aren't cached against the guest's wishes.
> -	 *
> -	 * Note, KVM may still ultimately ignore guest MTRRs for certain PFNs,
> -	 * e.g. KVM will force UC memtype for host MMIO.
> +	 * When EPT is enabled (shadow_memtype_mask is non-zero), and the VM
> +	 * has non-coherent DMA (DMA doesn't snoop CPU caches), KVM's ABI is to
> +	 * honor the memtype from the guest's PAT so that guest accesses to
> +	 * memory that is DMA'd aren't cached against the guest's wishes.  As a
> +	 * result, KVM _may_ ignore guest PAT, whereas without non-coherent DMA,
> +	 * KVM _always_ ignores guest PAT (when EPT is enabled).
>  	 */
> -	return vm_has_noncoherent_dma && shadow_memtype_mask;
> +	return shadow_memtype_mask;
>  }
>  

Any special reason to use the naming 'may_ignore_guest_pat', but not
'may_honor_guest_pat'?

Since it is also controlled by other cases, e.g., kvm_arch_has_noncoherent_dma()
at vmx_get_mt_mask(), it can be 'may_honor_guest_pat' too?

Therefore, why not directly use 'shadow_memtype_mask' (without the API), or some
naming like "ept_enabled_for_hardware".


Even with the code from PATCH 5/5, we still have high chance that VM has
non-coherent DMA?

 bool kvm_mmu_may_ignore_guest_pat(void)
 {
 	/*
-	 * When EPT is enabled (shadow_memtype_mask is non-zero), and the VM
+	 * When EPT is enabled (shadow_memtype_mask is non-zero), the CPU does
+	 * not support self-snoop (or is affected by an erratum), and the VM
 	 * has non-coherent DMA (DMA doesn't snoop CPU caches), KVM's ABI is to
 	 * honor the memtype from the guest's PAT so that guest accesses to
 	 * memory that is DMA'd aren't cached against the guest's wishes.  As a
 	 * result, KVM _may_ ignore guest PAT, whereas without non-coherent DMA,
-	 * KVM _always_ ignores guest PAT (when EPT is enabled).
+	 * KVM _always_ ignores or honors guest PAT, i.e. doesn't toggle SPTE
+	 * bits in response to non-coherent device (un)registration.
 	 */
-	return shadow_memtype_mask;
+	return !static_cpu_has(X86_FEATURE_SELFSNOOP) && shadow_memtype_mask;
 }


Thank you very much!

Dongli Zhang