On 17/09/19 11:33, Vitaly Kuznetsov wrote: > Jim Mattson <jmattson@xxxxxxxxxx> writes: > >> On Mon, Sep 16, 2019 at 9:23 AM Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: >>> >>> Hyper-V 2019 doesn't expose MD_CLEAR CPUID bit to guests when it cannot >>> guarantee that two virtual processors won't end up running on sibling SMT >>> threads without knowing about it. This is done as an optimization as in >>> this case there is nothing the guest can do to protect itself against MDS >>> and issuing additional flush requests is just pointless. On bare metal the >>> topology is known, however, when Hyper-V is running nested (e.g. on top of >>> KVM) it needs an additional piece of information: a confirmation that the >>> exposed topology (wrt vCPU placement on different SMT threads) is >>> trustworthy. >>> >>> NoNonArchitecturalCoreSharing (CPUID 0x40000004 EAX bit 18) is described in >>> TLFS as follows: "Indicates that a virtual processor will never share a >>> physical core with another virtual processor, except for virtual processors >>> that are reported as sibling SMT threads." From KVM we can give such >>> guarantee in two cases: >>> - SMT is unsupported or forcefully disabled (just 'disabled' doesn't work >>> as it can become re-enabled during the lifetime of the guest). >>> - vCPUs are properly pinned so the scheduler won't put them on sibling >>> SMT threads (when they're not reported as such). >> >> That's a nice bit of information. Have you considered a mechanism for >> communicating this information to kvm guests in a way that doesn't >> require Hyper-V enlightenments? >> > > (I haven't put much thought in this) but can we re-use MD_CLEAR CPUID > bit for that? Like if the hypervisor can't guarantee usefulness > (e.g. when two random vCPUs can be put on sibling SMT threads) of > flushing, is there any reason to still make the guest think the feature > is there? Yes, that's a good idea. Paolo
