[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/4] x86: Read MSR_ARCH_CAPS after early_microcode_init()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 12 Jun 2023 19:25:24 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oKaei8jJbFPtsU5mX37+5Or1yZTyrZayO/kjmCynmNQ=; b=RrW3VtmhVrOb5cbR/Hw6z8jAFre9AnfIbuYk1YMvv/sPMyPij8eBYt6vAHs7Pv2yuBBlCjqiIsx9W3HtZhyRM0X2DOGuGD6/rZNiRYjDzbgyaE+Eb3V0UB3EHah8mW+aMH/2zlhDi+9WTwjKLij4dxk0i9KX6Jwq+WziaDDO+Jv63U3q0Br2cKO2hNgBLmrFnJGM48bgsmMG3xD1a7D8fV+zFhItBkzwIgleRw5H7gULNDoSizuy0Wyd0wEUmVbspMcE9hVQtKVYC80kvpBO9xYlzLdPUy4EOyYmuSfZsfOrg4cL1bPTut5narOHJa/thQu8xblVCEmI6JhcFYWH5A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aEl/6EZezP0mz5Cc1ru7FfIA//xlKN65UKLgjRwgAEvohls6OYCzEbQrFeRStOWdGFfB3OmwOqkiC4WjH0TjA2nG62UkyoSZlauE0ivPfdCi9ZncYrZ3mrFk1esTkqopPA43DbSLtkF7YV3nvlkCzzKb4PxyhVDnNNMFsyt3WywwcQXNaXkrzABxjhewIt01ShLyeu9nBQkGezfthRxOL5lbXH4XNk+8wXTWBAyZZSRxBDnoPsXfkCKQnvb2puQ5qgAusD5ELMZLb36Ge+45oXVTpen+L/nrAutKFsZkcc73jvuiKR5yzCBtL6xTltjz5fRUV1XBILVBd8aA08J7rg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 12 Jun 2023 18:25:57 +0000
  • Ironport-data: A9a23:RWVngammkw/ZsgO8WG3klefo5gxBJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xIYXG+DbPfba2P9fd4kOYS2p0oC7ZfQzN5lSAo/ri8wRSMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6U6icfHgqH2eIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE0p5KyaVA8w5ARkPqgV5QWGzRH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 aMiB2svdz29vcfswKqUU6pLtJ08JuC+aevzulk4pd3YJdAPZMmbBo/suppf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVk1Q3ieC9WDbWUoXiqcF9t0CUv G/ZuU/+BQkXLoe3wjuZ6HO8wOTImEsXXapLTeTorac03wT7Kmo7IRoXSnWYrqGA1WGHYI5iJ 2oV2gEBlP1nnKCsZpynN/Gim1aGtBMBX9tbE8Uh9RqAjKHT5m6xD2wJTDdHZMYh8tE/QTgn1 FihlNfuGDApu7qQIVqC8p+EoDX0PjIaRUcSaClBQQYb7t3LpIAokgmJXttlCLSyjND+BXf32 T/ikcQlr7AajMpO3aPk+1nC2mqovsKQFl5z4RjLVGW46A8/fJSie4Gj9Vnc67BHMZqdSV6C+ nMDnqBy8dwzMH1ErwTVKM1lIV1jz6zt3OH06bK3I6Qcyg==
  • Ironport-hdrordr: A9a23:GD+seKoWuT3WRDgsT7htDvMaV5oReYIsimQD101hICG9JPbo8P xG+85rtiMc6QxwZJhOo7u90cW7K080lqQV3WByB9iftVLdyQ+VxehZhOPfKlvbdhEWndQy6U 4PScRD4HKbNykdsS5XijPIcerJYbO8gcWVuds=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12/06/2023 4:46 pm, Jan Beulich wrote:
> On 05.06.2023 19:08, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/cpu/microcode/core.c
>> +++ b/xen/arch/x86/cpu/microcode/core.c
>> @@ -840,6 +840,15 @@ static int __init early_microcode_update_cpu(void)
>>      return microcode_update_cpu(patch);
>>  }
>>  
>> +static void __init early_read_cpuid_7d0(void)
>> +{
>> +    boot_cpu_data.cpuid_level = cpuid_eax(0);
> As per above I don't think this is needed.
>
>> +    if ( boot_cpu_data.cpuid_level >= 7 )
>> +        boot_cpu_data.x86_capability[FEATURESET_7d0]
>> +            = cpuid_count_edx(7, 0);
> This is actually filled in early_cpu_init() as well, so doesn't need
> re-doing here unless because of a suspected change to the value (but
> then other CPUID output may have changed, too).

Hmm, yes.  I suspect that is due to the CET series (which needed to know
7d0 much earlier than previously), and me forgetting to clean up tsx_init().

>  At which point ...
>
>> @@ -878,5 +887,17 @@ int __init early_microcode_init(unsigned long 
>> *module_map,
>>      if ( ucode_mod.mod_end || ucode_blob.size )
>>          rc = early_microcode_update_cpu();
>>  
>> +    early_read_cpuid_7d0();
>> +
>> +    /*
>> +     * tsx_init() needs MSR_ARCH_CAPS, but it runs before identify_cpu()
>> +     * populates boot_cpu_data, so we read it here to centralize early
>> +     * CPUID/MSR reads in the same place.
>> +     */
>> +    if ( cpu_has_arch_caps )
>> +        rdmsr(MSR_ARCH_CAPABILITIES,
>> +              boot_cpu_data.x86_capability[FEATURESET_m10Al],
>> +              boot_cpu_data.x86_capability[FEATURESET_m10Ah]);
> ... "centralize" aspect goes away, and hence the comment needs adjusting.

I find it weird splitting apart the various reads into x86_capability[],
but in light of the feedback, only the rdmsr() needs to stay.

>
>> --- a/xen/arch/x86/tsx.c
>> +++ b/xen/arch/x86/tsx.c
>> @@ -39,9 +39,9 @@ void tsx_init(void)
>>      static bool __read_mostly once;
>>  
>>      /*
>> -     * This function is first called between microcode being loaded, and 
>> CPUID
>> -     * being scanned generally.  Read into boot_cpu_data.x86_capability[] 
>> for
>> -     * the cpu_has_* bits we care about using here.
>> +     * While MSRs/CPUID haven't yet been scanned, MSR_ARCH_CAPABILITIES
>> +     * and leaf 7d0 have already been read if present after early microcode
>> +     * loading time. So we can assume _those_ are present.
>>       */
>>      if ( unlikely(!once) )
>>      {
> I think I'd like to see at least the initial part of the original comment
> retained here.

The first sentence needs to stay as-is.  That's still relevant even with
the feature handling moved out.

The second sentence wants to say something like "However,
microcode_init() has already prepared the feature bits we need." because
it's the justification of why we don't do it here.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.