Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 19 May 2023 17:57:21 +0800
From:   Chao Gao <chao.gao@intel.com>
To:     Xiaoyao Li <xiaoyao.li@intel.com>
CC:     <kvm@vger.kernel.org>, Jiaan Lu <jiaan.lu@intel.com>,
        Zhang Chen <chen.zhang@intel.com>,
        Sean Christopherson <seanjc@google.com>,
        "Paolo Bonzini" <pbonzini@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 06/11] KVM: x86: Advertise ARCH_CAP_VIRTUAL_ENUM
 support
Message-ID: <ZGdIASx1lTamNaDd@chao-email>
References: <20230414062545.270178-1-chao.gao@intel.com>
 <20230414062545.270178-7-chao.gao@intel.com>
 <3b0f3295-27d7-4c83-e1cf-8494548ecf14@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3b0f3295-27d7-4c83-e1cf-8494548ecf14@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?XIz+abOPPR7iAWBRd1qOu74Lce+jTAPW+yMT8N3yIwlMcCEInFI/5MwAR+YY?=
 =?us-ascii?Q?DcEE0KSh5ts7CRucVAl+kgbzga2m6DD+cF4L6uNOKlK7iqJp3/xFlhPfK1eQ?=
 =?us-ascii?Q?nK8JgI5A0Ke6EpSNAPMUykp7eOzI9e4oswAwmiPWN8+gaWie61Uy+vnIlWvR?=
 =?us-ascii?Q?pWfODOnE5G95mEX/Hagp4nz5nXDKs2WxtxaMt/IStHzwC4wTG4w6AF/LaAyq?=
 =?us-ascii?Q?y5HXvp+5o833lDIE9ZERC8Wp/2giBh7/rIpjf6meJlDk8uLV+WJNr93DbD9e?=
 =?us-ascii?Q?BHROiB6tdC3vUO4bwFko8gMVNS5csCfYIRYRM/ryS3RmoINAI2qujIU8agPY?=
 =?us-ascii?Q?cDcXgggYgRX6yzM3YfycEtfR+wT6wAy20/rmoNNSrwS6O7kQ6l62pb6vej3n?=
 =?us-ascii?Q?lriRdh0WMJ43TarFBDHcWdbh8jMXl3G99TLF0F9svTMeU1Z+sYynDX1aSs0V?=
 =?us-ascii?Q?isvaUjWEvs5t5aDOeNN4ViKdbwYCp/fl2dFbR3rnzAf77wEezVDrFnSyIXfO?=
 =?us-ascii?Q?b3b5+Yr2U5khatsvtyJoiu8Bn9gvfPxN3YAp9sHQPgPg6Q3+G0K9/LgulJBE?=
 =?us-ascii?Q?3RfxyCo3e504+6S5SbmKph0fGpr63ibjBz85ajV97BrW10HdR1xcJWNTSoCW?=
 =?us-ascii?Q?6KDaPj15DEIr2bHu/iYeJxwOcbX2DzAcAYeGaVPyQWHyA1UbupFpPevcL5Is?=
 =?us-ascii?Q?VHCePSbAyuzZ8MKh3JTCDRmqmfUAb/r+AXNrzSgLR9heALYMjI0DaCF76CPS?=
 =?us-ascii?Q?LHCCYIGec8G43flBjjHMsfCcbyhhwII6CrVOqi+zK6f9Wbtx37Y954k0NQ5p?=
 =?us-ascii?Q?E5iHZjGxlQ5n98+ENpImwNDohrsMBogsdvg5Nl9tDVkfQcF/zyirnwmzAoVa?=
 =?us-ascii?Q?kPb8T0i2Lx39BC+poU8a+uRyrq3inBAJMACKXZSPtocGLtesAF/dK1hNhibR?=
 =?us-ascii?Q?4ghhq0RfVhVYFU/ET6qbLnB/iI92SCA6eZzo5KfGhUVZo756skPyYsQzeOKy?=
 =?us-ascii?Q?e+sP2qaJx2V0TggOytJFrB0b/8y0LD4JCG7f1FkOcYV+utHLjQ+8VnPzqN/b?=
 =?us-ascii?Q?AuSBj9Rq/6Z9m6tiFZfGMzQkRBdp+F/1cBwvlsXFKIp0jzIAAkWJa4C1Acb8?=
 =?us-ascii?Q?58SKssRv719IH/WX/ifRAIkvni50JFGq4V8ObCf6xv+4RnTKsB9MN8XDyhDm?=
 =?us-ascii?Q?VGBv5qBpMciZVO39qiGswbN6EB03Q8LjWh16GzOk0qjMj/NQYsFvV4TbIfIS?=
 =?us-ascii?Q?y39E7bdlhPdorM0mNulm5LYXkbtqItEMPwnkpL/WxG1rSf/0BGkmt6C3IY55?=
 =?us-ascii?Q?t3FKYSOO3y5s+uRyaPkggDN8ha06y33am3LRGmoDhzjZuiX4+2gNu+wMO5lT?=
 =?us-ascii?Q?9FuBE8wTIAv4DKznbIkKY6LAtqfrGoUokRtaWRIHHpVoJYiJJADWdho4xgp1?=
 =?us-ascii?Q?DxlclGBXkDuOVcg++eaaWfrtLuwj3pZ6L7YJlA1//JBCt7WkbHkWC2wclqtB?=
 =?us-ascii?Q?d0wrWEmZcj96DjUuTY9NMJtZ+UNRaRwRBArjxte61qOGdTS5aIzKDjc3jnFW?=
 =?us-ascii?Q?kTaS0uit9Oi8bbqAweo7BfGqr0cib7MC25ZHTfdj?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a7fff885-b773-400c-51b6-08db584f765f
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB6780.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2023 09:57:31.7677
 (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: 4SaW1dmMzqBqosB+ASo9XDCnxvkFMtOySSRvrsICVvuMLZZIOe4KEYmxLntHO59L0qWpHaKqJhjHc4tAj/lCWA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5368
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, May 18, 2023 at 06:14:40PM +0800, Xiaoyao Li wrote:
>>   static u32 msr_based_features[ARRAY_SIZE(msr_based_features_all)];
>> @@ -1591,7 +1593,8 @@ static unsigned int num_msr_based_features;
>>   	 ARCH_CAP_SKIP_VMENTRY_L1DFLUSH | ARCH_CAP_SSB_NO | ARCH_CAP_MDS_NO | \
>>   	 ARCH_CAP_PSCHANGE_MC_NO | ARCH_CAP_TSX_CTRL_MSR | ARCH_CAP_TAA_NO | \
>>   	 ARCH_CAP_SBDR_SSDP_NO | ARCH_CAP_FBSDP_NO | ARCH_CAP_PSDP_NO | \
>> -	 ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO)
>> +	 ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO | \
>> +	 ARCH_CAP_VIRTUAL_ENUM)
>
>We cannot do it.
>
>Otherwise, an AMD L1 with X86_FEATURE_ARCH_CAPABILITIES configured is
>possible to expose MSR_VIRTUAL_ENUMERATION to L2 while no support for it.

How does AMD L1 see the ARCH_CAP_VIRTUAL_ENUM feature in the first
place? because ...

>
>>   static u64 kvm_get_arch_capabilities(void)
>>   {
>> @@ -1610,6 +1613,17 @@ static u64 kvm_get_arch_capabilities(void)
>>   	 */
>>   	data |= ARCH_CAP_PSCHANGE_MC_NO;
>> +	/*
>> +	 * Virtual enumeration is a paravirt feature. The only usage for now
>> +	 * is to bridge the gap caused by microarchitecture changes between
>> +	 * different Intel processors. And its usage is linked to "virtualize
>> +	 * IA32_SPEC_CTRL" which is a VMX feature. Whether AMD SVM can benefit
>> +	 * from the same usage and how to implement it is still unclear. Limit
>> +	 * virtual enumeration to VMX.
>> +	 */
>> +	if (static_call(kvm_x86_has_emulated_msr)(NULL, MSR_VIRTUAL_ENUMERATION))
>> +		data |= ARCH_CAP_VIRTUAL_ENUM;

the feature is exposed on Intel CPUs only.

Do you mean AMD L1 created on Intel L0? and Intel L0 even emulates
nested (SVM) support for the L1? This sounds a very contrived case.

>> +
>>   	/*
>>   	 * If we're doing cache flushes (either "always" or "cond")
>>   	 * we will do one whenever the guest does a vmlaunch/vmresume.
>