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

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 24 Aug 2021 17:15:09 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=PuS99CRn7YeJd8GNv75Es8p1OswvHb7nNq/zIRRWXZE=; b=AZfbye+wzK7NdQa/Cvn+uFt7XYlbsdzcZyYJ/uUu1MQPYEFtjQQDG3Jhy1Niyb4RbucBctgn44XHi2VrfVPwj/3mC+Qan9ag+ixBEQFIReGIBF/1wPrg51alD3xlwEM8ohsllnaxHgVjea0zuezPuTiQH2mML3ROkamnZymivWm087lLtiHFLUxq1dVrNQI/xGoR+OEALQvBG5lQ++O+w79jrzFLt8xvuJ31yfbXN3LuIGsqO1xuE0fH5ZAQRxR203LTWIEPRBlALNx7NW92BiJ0AWcvOnh4L75h0vGsiF6QVIZ7zqkOxfbTJJEi4Du55JyJQzL7PIOTCAZe7vWXnQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dm3Rk7dbRYCZ5elJCHd0PeEXdgflTGayJDrKAhLh5bbiODkrLuR8INtdXAhCG/LGPbvGHXaFmNCzXsB/K2qsyMuD+LTOIqA5HfvnPlT11mCPCXAJ8m+SEyIU9b/35rGyTBx7Nfgj/AUDN9leV/4y7AHBq+eXrXuzg8r5cJs75ZQUC41X7nHjYTVkOHmqj5w17tpLfBHITaZPx3r0aom5Ud+E7Abr2RbnpNi8/fG5WMHCP1Ge5WBaRifSGcjxiCs2cmCLFHTzj0FwWShmjkS3+hzfn/Tx+kcRmgvLWrXQW6s8CdoU293VyrWGA4olFpeqSGaJB3QEXN2RTwJDS8bsUQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Aug 2021 15:15:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.08.2021 15:26, Andrew Cooper wrote:
> 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.

I'm curious as to why you think so.

>  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.

Then better stay with what you have I would say - for me "psmp"
immediately raises the question "What strange kind of SMP?"
While not tied to any formal naming, I could see "ibrs-sm" as
an option ...

Jan




 


Rackspace

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