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

Re: [PATCH v1 2/2] x86/cpuid: Detect null segment behaviour on Zen2 CPUs


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Jane Malalane <jane.malalane@xxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 6 Sep 2021 19:07:40 +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; bh=0Mncjb0+JPGtlBvhg0XIVHAc93gaDfzgSaMk3YdIyJU=; b=ae+2/oq0Jzfk8uYwF0/lk1izupG7YWdXafG3G6ll7M5604SJODsMqptpVEGWj056AshtpKW/YqhrFfU0SaN7Q2fVCWJhh1Cnfg8QPSMySInZ+0crvyUUSADKH1Odv4ShQUCrMt/bIQ0QhDytMUGiOIyIM8id/tv8L44LMUuIKLjGwrXjaBYRXvByhOqc/eogob4v8fge2rYAjFL57GDW2xmTE8ODg+UqJobZwroRphA/ORl04/tr3MoShrHJXnxX1blPSC/Lw/wupNtTiVmh46+Ed79Cr43gbt1RiKswHxwQCMjOXfA2wE2Am3PGku1f/KEJVVW8WIo0I6fywClFIw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZ2VpO9mG+T2NomCSkFdTBk6E8i4I2vO52EcQbhCplkCSy+2HGAcXbDxkwlZCdR6NIZtlsDrVQZcxTDJendbn0r4kNmYOUwHRP8gg2I23H6ytuTsIFFiJ+cQsfINESBEfS9gbGg+XAi+fuu7MjXpO4OopXPU5jE6BPnQrXAZBrZDCIVoe9db1d22aq//BCpmRoqFVN0gQCa1OfD1IlZpqmnKnhQX46OpORsLKQcE3OqiBS3aZwdBh6EDjwN/HuGeMOgXdMKEIRH3fwhdXlO0puHo8UJqHoIa0f1jgVx4B0zhgJP4tRhBhwCm3KDY8iJzNrqQJOscH1Gqwwb3sG6fFg==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Pu Wen <puwen@xxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 06 Sep 2021 18:07:59 +0000
  • Ironport-hdrordr: A9a23:6na8C60Dd1DnAUXj3ligFQqjBLYkLtp133Aq2lEZdPUzSL3+qy nOpoV+6faQsl0ssR4b9exoVJPufZq+z/5ICOsqU4tKNTOO0AHEEGgI1+rf6gylNyri9vNMkY dMGpIObeEY1GIK7voSNjPIceod/A==
  • Ironport-sdr: dEaSWqBoj63gUhgCCQ+WlgRYldYcv7Eds+6ZAI+mjCtvfQTL5D/hm9//plqEFfMNSkrW713r9J Nj2h1d/9RKP/VTvg3MMyI5Kv/mi62S4M/Qxh1xVqbPO3cF7VYp5vACZ62EbyhbloBBlQ/pDgaM ttE4QrcIYbNb/ugqmIBbLZorthWMk6AHPlyaqo9Jxh3ZO4epj1VSqn+PCWtwbEPFWvW1Slm9H2 NZu/Dr7t4D7zAGj2/LaUErcxvSrHFcK03ZYzWLp4kqZZIXdcRfwseoq66C9NqBV27LLa+Ye15M JLp1yXyebgh0TJFYuo/4UYDa
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06/09/2021 16:17, Jan Beulich wrote:
> On 06.09.2021 14:00, Jane Malalane wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -681,6 +681,19 @@ void amd_init_lfence(struct cpuinfo_x86 *c)
>>                        c->x86_capability);
>>  }
>>  
>> +void detect_zen2_null_seg_behaviour(void)
> This can in principle be marked __init.
>
>> +{
>> +    uint64_t base;
>> +
>> +    wrmsrl(MSR_FS_BASE, 1);
>> +    asm volatile ( "mov %0, %%fs" :: "rm" (0) );
> While I don't strictly mind the "m" part of the constraint to remain
> there (in the hope for compilers actually to support this), iirc it's
> not useful to have when the value is a constant: Last time I checked,
> the compiler would not instantiate an anonymous (stack) variable to
> fulfill this constraint (as can be seen when dropping the "r" part of
> the constraint).

This is "rm" because it is what we use elsewhere in Xen for selectors,
and because it is the correct constraints based on the legal instruction
encodings.

If you want to work around what you perceive to be bugs in compilers
then submit a independent change yourself.

>> @@ -731,6 +744,11 @@ static void init_amd(struct cpuinfo_x86 *c)
>>      else /* Implicily "== 0x10 || >= 0x12" by being 64bit. */
>>              amd_init_lfence(c);
>>  
>> +    /* Probe for NSCB on Zen2 CPUs when not virtualised */
>> +    if (!cpu_has_hypervisor && !cpu_has_nscb && c == &boot_cpu_data &&
>> +        c->x86 == 0x17 && c->x86_model >= 30 && c->x86_model <= 0x5f)
> DYM 0x30 here?

0x30, although it turns out that some of the mobile Zen2 CPUs exceed
0x60 in terms of model number.

As Zen3 changes the family number to 0x19, I'd just drop the upper bound.

>  Or 0x1e? In any event 0x5f should be accompanied by
> another hex constant. And it would also help if in the description
> you said where these bounds

>From talking to people at AMD.

>  as well as ...
>
>> --- a/xen/arch/x86/cpu/hygon.c
>> +++ b/xen/arch/x86/cpu/hygon.c
>> @@ -34,6 +34,11 @@ static void init_hygon(struct cpuinfo_x86 *c)
>>  
>>      amd_init_lfence(c);
>>  
>> +    /* Probe for NSCB on Zen2 CPUs when not virtualised */
>> +    if (!cpu_has_hypervisor && !cpu_has_nscb && c == &boot_cpu_data &&
>> +        c->x86 == 0x18 && c->x86_model >= 4)
> ... this one come from.

>From talking to people at Hygon.

~Andrew




 


Rackspace

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