arch/x86/xen/enlighten.c | 8 ++++++++ arch/x86/xen/enlighten_hvm.c | 2 ++ arch/x86/xen/enlighten_pv.c | 2 ++ arch/x86/xen/xen-ops.h | 2 ++ 4 files changed, 14 insertions(+)
When running as a Xen guest selecting "nosmt" either via command line
or implicitly via default settings makes no sense, as the guest has no
clue about the real system topology it is running on. With Xen it is
the hypervisor's job to ensure the proper bug mitigations are active
regarding smt settings.
So when running as a Xen guest set cpu_smt_control to "not supported"
in order to avoid disabling random vcpus.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
arch/x86/xen/enlighten.c | 8 ++++++++
arch/x86/xen/enlighten_hvm.c | 2 ++
arch/x86/xen/enlighten_pv.c | 2 ++
arch/x86/xen/xen-ops.h | 2 ++
4 files changed, 14 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 750f46ad018a..312b73698d0c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -345,3 +345,11 @@ void xen_arch_unregister_cpu(int num)
}
EXPORT_SYMBOL(xen_arch_unregister_cpu);
#endif
+
+void __init xen_disable_nosmt(void)
+{
+#ifdef CONFIG_HOTPLUG_SMT
+ /* Don't allow SMT disabling in Xen guests. */
+ cpu_smt_control = CPU_SMT_NOT_SUPPORTED;
+#endif
+}
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 0e75642d42a3..7c62662cd2ca 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -116,6 +116,8 @@ static void __init init_hvm_pv_info(void)
this_cpu_write(xen_vcpu_id, ebx);
else
this_cpu_write(xen_vcpu_id, smp_processor_id());
+
+ xen_disable_nosmt();
}
#ifdef CONFIG_KEXEC_CORE
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4722ba2966ac..dcfec65bca60 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -131,6 +131,8 @@ static void __init xen_pv_init_platform(void)
/* pvclock is in shared info area */
xen_init_time_ops();
+
+ xen_disable_nosmt();
}
static void __init xen_pv_guest_late_init(void)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 2f111f47ba98..63a31b9d7217 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -161,4 +161,6 @@ void xen_hvm_post_suspend(int suspend_cancelled);
static inline void xen_hvm_post_suspend(int suspend_cancelled) {}
#endif
+void __init xen_disable_nosmt(void);
+
#endif /* XEN_OPS_H */
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel>>> On 12.06.19 at 12:12, <jgross@suse.com> wrote: > When running as a Xen guest selecting "nosmt" either via command line > or implicitly via default settings makes no sense, as the guest has no > clue about the real system topology it is running on. With Xen it is > the hypervisor's job to ensure the proper bug mitigations are active > regarding smt settings. I don't agree with the second sentence: It is in principle fine for the hypervisor to expose HT (i.e. not disable it as bug mitigation), and leave it to the guest kernels to protect themselves. We're just not at the point yet where Xen offers sufficient / reliable data to guest kernels to do so, so _for the time being_ what you say is correct. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On 12.06.19 12:19, Jan Beulich wrote: >>>> On 12.06.19 at 12:12, <jgross@suse.com> wrote: >> When running as a Xen guest selecting "nosmt" either via command line >> or implicitly via default settings makes no sense, as the guest has no >> clue about the real system topology it is running on. With Xen it is >> the hypervisor's job to ensure the proper bug mitigations are active >> regarding smt settings. > > I don't agree with the second sentence: It is in principle fine for the > hypervisor to expose HT (i.e. not disable it as bug mitigation), and > leave it to the guest kernels to protect themselves. We're just not > at the point yet where Xen offers sufficient / reliable data to guest > kernels to do so, so _for the time being_ what you say is correct. Okay, I'll add something like: This is true as long Xen doesn't support core scheduling together with exposing the (then) correct sibling information to the guest and indicating that case via a sutable interface. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On Wed, Jun 12, 2019 at 12:12:28PM +0200, Juergen Gross wrote: > When running as a Xen guest selecting "nosmt" either via command line > or implicitly via default settings makes no sense, as the guest has no > clue about the real system topology it is running on. With Xen it is > the hypervisor's job to ensure the proper bug mitigations are active > regarding smt settings. > > So when running as a Xen guest set cpu_smt_control to "not supported" > in order to avoid disabling random vcpus. If it doesn't make sense; then the topology should not expose SMT threads and the knob will not have any effect. If you expose SMT topology info to the guest, then you get what you ask for. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On 12.06.19 13:48, Peter Zijlstra wrote: > On Wed, Jun 12, 2019 at 12:12:28PM +0200, Juergen Gross wrote: >> When running as a Xen guest selecting "nosmt" either via command line >> or implicitly via default settings makes no sense, as the guest has no >> clue about the real system topology it is running on. With Xen it is >> the hypervisor's job to ensure the proper bug mitigations are active >> regarding smt settings. >> >> So when running as a Xen guest set cpu_smt_control to "not supported" >> in order to avoid disabling random vcpus. > > If it doesn't make sense; then the topology should not expose SMT > threads and the knob will not have any effect. Yes, that's the theory. I agree completely, but this is ongoing work which will need some more time. It probably would have been ready for some time now, but some recent processor bugs required a shift in priorities what to do first. In order to run a new kernel on existing Xen we need that patch to avoid disabling random cpus. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
© 2016 - 2024 Red Hat, Inc.