Hi Julien,
On 3/15/2024 6:58 PM, Julien Grall wrote:
On 14/03/2024 14:22, Henry Wang wrote:
Hi Julien,
Hi,
/* representing HT siblings of each logical CPU */
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
/* representing HT and core siblings of each logical CPU */
@@ -89,6 +88,10 @@ static int setup_cpu_sibling_map(int cpu)
cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+ /* Currently we assume there is no multithread. */
I am not very familiar with the scheduling in Xen. Do you know
what's the consequence of not properly supporting MT? One thing I
can think of is security (I know there were plenty of security
issues with SMT).
Unfortunately me neither, so adding George to this thread as I think
he can bring us some insights on this topic from the scheduler
perspective.
+Juergen as he worked on co-scheduling.
Thanks.
Depending on the answer, I would consider to print a warning and
maybe add it in SUPPORT.MD in a separate patch.
To be honest, as discussed in v1. I think I am quite tempted to add
an ASSERT(system_cpuinfo.mpidr.mt == 0) to make sure we catch the
multithread support stuff earlier.
ASSERT(...) is not the right solution. You may have user using a Xen
shipped by distros where this would be a NOP.
We could try to hide MT completely from the scheduler. If that's too
difficult, then we could add use warning_add() to throw a warning (see
how we dealt with opt_hmp_unsafe).
Ok. Let's first see what George and Juergen will say, if MT cannot be
hidden from scheduler for Arm, maybe we can add something like below:
if ( system_cpuinfo.mpidr.mt == 1 )
warning_add("WARNING: MULTITHREADING HAS BEEN DETECTED ON THE
PROCESSOR.\n"
"It might impact the security and
stability of the system.\n");
Kind regards,
Henry
