| Message ID | 20190916162258.6528-2-vkuznets@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: hyper-v: make L2 Hyper-V 2019 on KVM guests see MD_CLEAR | expand |
On Mon, Sep 16, 2019 at 9:23 AM Vitaly Kuznetsov <vkuznets@redhat.com> wrote: > > KVM needs to know if SMT is theoretically possible, this means it is > supported and not forcefully disabled ('nosmt=force'). Create and > export cpu_smt_possible() answering this question. It seems to me that KVM really just wants to know if the scheduler can be trusted to avoid violating the invariant expressed by the Hyper-V enlightenment, NoNonArchitecturalCoreSharing. It is possible to do that even when SMT is enabled, if the scheduler is core-aware. Wouldn't it be better to implement a scheduler API that told you exactly what you wanted to know, rather than trying to infer the answer from various breadcrumbs?
On 16/09/19 19:16, Jim Mattson wrote: >> KVM needs to know if SMT is theoretically possible, this means it is >> supported and not forcefully disabled ('nosmt=force'). Create and >> export cpu_smt_possible() answering this question. > It seems to me that KVM really just wants to know if the scheduler can > be trusted to avoid violating the invariant expressed by the Hyper-V > enlightenment, NoNonArchitecturalCoreSharing. It is possible to do > that even when SMT is enabled, if the scheduler is core-aware. > Wouldn't it be better to implement a scheduler API that told you > exactly what you wanted to know, rather than trying to infer the > answer from various breadcrumbs? Yes, however that scheduler API could also rely on something like cpu_smt_possible(), at least in the case where core scheduling is not active, so this is still a step in the right direction. Paolo
Jim Mattson <jmattson@google.com> writes: > On Mon, Sep 16, 2019 at 9:23 AM Vitaly Kuznetsov <vkuznets@redhat.com> wrote: >> >> KVM needs to know if SMT is theoretically possible, this means it is >> supported and not forcefully disabled ('nosmt=force'). Create and >> export cpu_smt_possible() answering this question. > > It seems to me that KVM really just wants to know if the scheduler can > be trusted to avoid violating the invariant expressed by the Hyper-V > enlightenment, NoNonArchitecturalCoreSharing. It is possible to do > that even when SMT is enabled, if the scheduler is core-aware. > Wouldn't it be better to implement a scheduler API that told you > exactly what you wanted to know, rather than trying to infer the > answer from various breadcrumbs? (I know not that much about scheduler so please bear with me) Having a trustworthy scheduler not placing unrelated (not exposed as sibling SMT threads to a guest or vCPUs from different guests) on sibling SMT threads when it's not limited with affinity is definitely a good thing. We, however, also need to know if vCPU pinning is planned for the guest: like when QEMU vCPU threads are created they're not pinned, however, libvirt pins them if needed before launching the guest. So 'NoNonArchitecturalCoreSharing' can also be set in two cases: - No vCPU pinning is planned but the scheduler is aware of the problem (I'm not sure it is nowadays) - The upper layer promises to do the right pinning. This patch series, however, doesn't go that deep, it only covers the simplest case: SMT is unavailable or forcefully disabled. I'll try to learn more about scheduler though.
diff --git a/include/linux/cpu.h b/include/linux/cpu.h index fcb1386bb0d4..6d48fc456d58 100644 --- a/include/linux/cpu.h +++ b/include/linux/cpu.h @@ -201,12 +201,14 @@ enum cpuhp_smt_control { extern enum cpuhp_smt_control cpu_smt_control; extern void cpu_smt_disable(bool force); extern void cpu_smt_check_topology(void); +extern bool cpu_smt_possible(void); extern int cpuhp_smt_enable(void); extern int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval); #else # define cpu_smt_control (CPU_SMT_NOT_IMPLEMENTED) static inline void cpu_smt_disable(bool force) { } static inline void cpu_smt_check_topology(void) { } +static inline bool cpu_smt_possible(void) { return false; } static inline int cpuhp_smt_enable(void) { return 0; } static inline int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) { return 0; } #endif diff --git a/kernel/cpu.c b/kernel/cpu.c index e84c0873559e..2f8c2631e641 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -389,8 +389,7 @@ enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED; void __init cpu_smt_disable(bool force) { - if (cpu_smt_control == CPU_SMT_FORCE_DISABLED || - cpu_smt_control == CPU_SMT_NOT_SUPPORTED) + if (!cpu_smt_possible()) return; if (force) { @@ -435,6 +434,14 @@ static inline bool cpu_smt_allowed(unsigned int cpu) */ return !per_cpu(cpuhp_state, cpu).booted_once; } + +/* Returns true if SMT is not supported of forcefully (irreversibly) disabled */ +bool cpu_smt_possible(void) +{ + return cpu_smt_control != CPU_SMT_FORCE_DISABLED && + cpu_smt_control != CPU_SMT_NOT_SUPPORTED; +} +EXPORT_SYMBOL_GPL(cpu_smt_possible); #else static inline bool cpu_smt_allowed(unsigned int cpu) { return true; } #endif
KVM needs to know if SMT is theoretically possible, this means it is supported and not forcefully disabled ('nosmt=force'). Create and export cpu_smt_possible() answering this question. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> --- include/linux/cpu.h | 2 ++ kernel/cpu.c | 11 +++++++++-- 2 files changed, 11 insertions(+), 2 deletions(-)