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

Re: [PATCH 3/5] x86/msr: Expose MSR_ARCH_CAPS in the raw and host policies


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 14 Jun 2021 15:10:03 +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=ICjZXqrRU8UXH0K0zEPXPvDmMNtwCUB+TF9uMGEWTzQ=; b=Lnues2u/73fGe3F8IriMGaMaaENaZuwlqPSnz5Jm6v92DiIesWBw7yPc0jDuVKD1y31krMNepCygA3p6Vl7SpuqklMNz4doXLesF4ezJrgSobrvVVuJsVJotv9KHcGRoB/Veqp9MyPj4YFHgoLQZ6k936LGVUTx8CJebrWT10VUmVtbzSPEpG7Hopg2Is96p/8KSQs971gUKQOd5DmyIgHuEKNfQVYmVjZWyrSIYKuDkB2ezTp3DwwvyFBKoDIx5JxvhtCX4G4GcLthd+/QVXFYnFrobH2V06ajRa0YTNbiYb+kD1ohaMhoXjphys4uU9dzHHFrHL3Dw+44XmxPK7A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MuFs+8p7qwYDC+3OjIe1CZgfKhurNzQxDN2ixs4YXeUtTDTawrblzZ3GvYlLxzhbJGwwmOrHZQr+f8ntQQyOsXrAJ10nEQq9uDVOUlyrjXocM25OH/8UycCK3oxUDNtziUdkqasjt4ntii7IiKUQJH1ze1Jpw/UbFoopYmXzdwdvXJVQvhbeufp76gdqfEs3ORK+Ql8iSWG63Exv9e8r9GUt+E4cXL3rBQbgJPbzPoSPJ3sbJicPvU/wYhq7Jo8P9gaGPl/E6ZzHCiyR6jwcbf3F4sy7k8blgMolu67FXmV/qexKEiynWrVDGh0nCyEvy2yMEFi2CCeBOddL4fyW2A==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>, Edwin Torok <edvin.torok@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 14 Jun 2021 14:10:21 +0000
  • Ironport-hdrordr: A9a23:cTSrY6gGLH0jzR1dCPaHXfkQpnBQXz513DAbv31ZSRFFG/FwyP rBoB1L73DJYWgqNE3I+erhBEGBKUmskaKdkrNhQ4tKOzOWx1dATbsSkbcKpgeAJ8SQzJ8n6U 4NSdkZNDS0NykGsS+Y2njLLz9D+qj+zEnAv463pB0BPGIaCdAV0+46MHf9LqQffng0OXNTLu vk2iMonUvERZ1aVLXAOpFTNNKz1+Ej2aiWLyIuNloC0k2jnDmo4Ln1H1yx2QofaSpGxfMH/X LemwL0y62/u7XjoyWsl1P73tBzop/M29FDDMuDhow8LSjtsB+hYMBEV6eZtD44jemz4BIBkc XKoT0nI8NvgkmhP12dkF/I4U3NwTwu43jtxRuzmn34u/H0Qzo8Fo5omZ9ZWgGx0TtkgPhMlI Zwm06JvZteCh3N2A7n4cLTah1snk2o5VI/jO8oiWBFW4d2Us4SkWUmxjITLH48JlO91Gh+e9 MeVf00pcwmMm9yVkqp+lWGm7eXLywO9n7seDl2hiSXuwIm0UyRgXFon/D2Mx87hdoAoqJ/lp L525JT5ftzp/8tHNVA7dg6MIKK40z2MF7x2TGpUBva/J9uAQOHl3eh2sRF2AjtQu1T8KcP
  • Ironport-sdr: wPASZuPBYB7ENqapSMODNBlCJUfD6vLLxVVSyuJqieKDb3QUyunkavz7WrL7bp/3A2b2+jCyui l3EzmDP1Wsuvo4Afn3+3mpo15U+1NY/k1C7tD3BgShkTI17XhcX+OMKheF9qNyugIGvw1QSbX/ AH3A/twQIBkYqKZSLyCD3DV4tF4beNMCMNuD9nB05v9A26kIFstwMyBDvzQFtmyZQgsdTAKewE DOmsCVNdpKi1sZlqhxEZ4J8yv1SYZ1q8Ynl1cmPJ8D2NMelOrrchWOvtYTCo38/LrTvAsG4EwG 7/g=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 14/06/2021 13:57, Jan Beulich wrote:
> On 11.06.2021 18:36, Andrew Cooper wrote:
>> @@ -60,6 +65,11 @@ static void __init calculate_host_policy(void)
>>      /* 0x000000ce  MSR_INTEL_PLATFORM_INFO */
>>      /* probe_cpuid_faulting() sanity checks presence of 
>> MISC_FEATURES_ENABLES */
>>      mp->platform_info.cpuid_faulting = cpu_has_cpuid_faulting;
>> +
>> +    mp->arch_caps.raw &=
>> +        (ARCH_CAPS_RDCL_NO | ARCH_CAPS_IBRS_ALL | ARCH_CAPS_RSBA |
>> +         ARCH_CAPS_SKIP_L1DFL | ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO |
>> +         ARCH_CAPS_IF_PSCHANGE_MC_NO | ARCH_CAPS_TSX_CTRL | 
>> ARCH_CAPS_TAA_NO);
>>  }
> Isn't this a little too simple? For CPUID we consider the host policy
> to be what Xen is using. Taking ARCH_CAPS_SKIP_L1DFL as an example,
> we're not using it unconditionally (depending on opt_md_clear_hvm and
> opt_l1d_flush), i.e. there's command line control over its use just
> like there is over the CPUID bits.

But we don't go clearing CPUID bits for features we choose not to use.

ARCH_CAPS_SKIP_L1DFL, despite its name, is a statement of how hardware
(and/or out outer hypervisor) behaves.

It means "you don't need to flush the L1D on VMEntry to mitigate L1TF",
whether or not we employ fine tuning to change what Xen does.

>  Or take ARCH_CAPS_RDCL_NO, which
> we set unilaterally for AMD/Hygon.

That is local to spec_ctrl.c, and a mistake in hindsight.  It was
written at a point in time when it wasn't clear whether AMD were going
to implement MSR_ARCH_CAPS or not.

The logic in spec_ctrl.c will change substantially when we load
microcode and collect the raw/host policies at the start of boot.

> I don't mind it remaining this simple for the moment, but then at
> least the commit message should state that this is currently over-
> simplifying things. If you agree, then with suitable wording added:
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

This is "mask all features not known by the Xen".  For CPUID bits, it's
done by the masking against known_features[] (autogenerated by
gen-cpuid.py), but we have no equivalent for MSRs yet.

We're definitely going to have to invent something (VT-x is going to be
a total nightmare without it), but I haven't got any clever ideas right now.

I'm happy to insert a comment saying that this is a substitute for not
having known_features[] for MSR bits yet.

~Andrew




 


Rackspace

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