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

Re: [PATCH 2/3] x86/amd: Enumeration for speculative features/hints


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 24 Aug 2021 14:26:27 +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-SenderADCheck; bh=d/VZWn5+2hGrIz3nmZ40y8mKPowdTAccDunKosmnRww=; b=aURXQ2qzXkrQK09NUo0eZAv7YLC4ebYUeVWe9vNZNdOy8UVuF00mBpXaubqf68r1X9fjVgVdFKROgJBXSPbZN5L/K4UQI0x7WAunevjSfFdJhsg2vvM1X5m0y9krNjDJMlh3uoENgJfFcJgtPMsaSayqA9Z90ALwVDQZE6DMNRwQi/2Q/nQZ5e3c9tJQVSBx4A/0CTWW++TRLJJe3JeQQ31i94MZ+FdXAnRe0Vdf+7f3he9qNp77eJxJ9eKD1qoPWSpqJT8r/rq55WFu4k6UGLYqAYRnO/wV/a642mC/Kq3f0TzKr1Xs92NmJaG5OCCl3bQPzHpivZaaYJ/8k/zcbA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fGzs+zwaR+lCmhFEwgDfyIQBxUqjV+E4LCHIZ7Kwp/IGljTVYJOLW2SfxgGaxnKUdGZJSpq3KbVNy0e9cbCpF5Nt0VRs6MstD3UBE+xZubxVKF8WSsJt9+RalAgI57oycfC96KHztweZL03zLdERdL4nglNanEoV0QdVDIFKFTvS4NekrfJU/vMvJ23NgOFmcGN2tymyYFepjPgXwAeIw2URuq1URe6qasj57XD1hGsf2N3Kbcy0ACgE8Cv67y7d0oiMDYZq61NFMyb3TXmY/D9tQPgjapEw4gzNbyh1b3fy2Vo60dAUy8UTSTozOsHz/ZAyrwY4qbTzkkgy9Xl2xw==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Aug 2021 13:26:44 +0000
  • Ironport-hdrordr: A9a23:8JMA6K4Q2jqeYqEdRgPXwDLXdLJyesId70hD6qkQc3FomwKj9/ xG/c5rsSMc7Qx6ZJhOo7+90cW7L080lqQFhLX5X43SPzUO0VHARO1fBOPZqAEIcBeOlNK1u5 0AT0B/YueAcGSTj6zBkXWF+wBL+qj5zEiq792usUuEVWtRGsZdB58SMHfhLqVxLjM2Y6YRJd 6nyedsgSGvQngTZtTTPAh+YwCSz+e77a4PeHQ9dmYa1DU=
  • Ironport-sdr: Hd3GifuYVJhJ7rbm73nNqYQFW1DtHmuwKxuEVmvS6kB00dfTeIhi+gRcIT73UV8CMOfcU2cl+H NZvRLyt6sCQacGz+G79oixWhTtLeICxXqrzvHKeIXvfDAqHRf09R2DksU/nd+k0o5ofjE2lCXW 79un/9oSClA8QiX58DyFCjO9swSSqTgz+UtkeZGkSvze0FLbhyWpCQy1yabKzSJI9mxyDRep/i 1pb3xDjG6RiTekqiB/AX6nf3Pqn9fMybCYcJJhdB15YzK/dYLY29/yXwU+9oP5SWi9lNMI8cI4 WRP8ESWIG6ztsIfbXELsUln9
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19/08/2021 15:47, Jan Beulich wrote:
> On 17.08.2021 16:30, Andrew Cooper wrote:
>> There is a step change in speculation protections between the Zen1 and Zen2
>> microarchitectures.
>>
>> Zen1 and older have no special support.  Control bits in non-architectural
>> MSRs are used to make lfence be dispatch-serialising (Spectre v1), and to
>> disable Memory Disambiguation (Speculative Store Bypass).  IBPB was
>> retrofitted in a microcode update, and software methods are required for
>> Spectre v2 protections.
>>
>> Because the bit controlling Memory Disambiguation is model specific,
>> hypervisors are expected to expose a MSR_VIRT_SPEC_CTRL interface which
>> abstracts the model specific details.
>>
>> Zen2 and later implement the MSR_SPEC_CTRL interface in hardware, and
>> virtualise the interface for HVM guests to use.  A number of hint bits are
>> specified too to help guide OS software to the most efficient mitigation
>> strategy.
>>
>> Zen3 introduced a new feature, Predictive Store Forwarding, along with a
>> control to disable it in sensitive code.
>>
>> Add CPUID and VMCB details for all the new functionality.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> with one suggestion:
>
>> --- a/tools/libs/light/libxl_cpuid.c
>> +++ b/tools/libs/light/libxl_cpuid.c
>> @@ -274,8 +274,18 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
>> *cpuid, const char* str)
>>          {"rstr-fp-err-ptrs", 0x80000008, NA, CPUID_REG_EBX, 2, 1},
>>          {"wbnoinvd",     0x80000008, NA, CPUID_REG_EBX,  9,  1},
>>          {"ibpb",         0x80000008, NA, CPUID_REG_EBX, 12,  1},
>> +        {"ibrs",         0x80000008, NA, CPUID_REG_EBX, 14,  1},
>> +        {"amd-stibp",    0x80000008, NA, CPUID_REG_EBX, 15,  1},
>> +        {"ibrs-always",  0x80000008, NA, CPUID_REG_EBX, 16,  1},
>> +        {"stibp-always", 0x80000008, NA, CPUID_REG_EBX, 17,  1},
>> +        {"ibrs-fast",    0x80000008, NA, CPUID_REG_EBX, 18,  1},
>> +        {"ibrs-same-mode", 0x80000008, NA, CPUID_REG_EBX, 19,  1},
> Here and below, how about dropping the "mode" part of the name?
> I can't seem to be able to think of any other "same" that could
> possibly apply here.

ibrs-same is very ambiguous.  The only other reasonable reasonable
alternative I can think of is ibrs-psmp as an abbreviation for
ProvideSameModeProtection.  Obviously, the "Provides" bit of that can't
be dropped.

~Andrew




 


Rackspace

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