x86/xen: disable nosmt in Xen guests
diff mbox series

Message ID 20190612101228.23898-1-jgross@suse.com
State New
Headers show
Series
  • x86/xen: disable nosmt in Xen guests
Related show

Commit Message

Juergen Gross June 12, 2019, 10:12 a.m. UTC
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(+)

Comments

Jan Beulich June 12, 2019, 10:19 a.m. UTC | #1
>>> 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
Juergen Gross June 12, 2019, 10:36 a.m. UTC | #2
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
Peter Zijlstra June 12, 2019, 11:48 a.m. UTC | #3
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.
Juergen Gross June 12, 2019, 2:59 p.m. UTC | #4
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

Patch
diff mbox series

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 */