On 14.06.2021 16:10, Andrew Cooper wrote: > 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 <[email protected]> > > 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.
Please do, and then I'm fine with it. Thanks, Jan
