[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v11 04/11] s390x/cpu topology: reporting the CPU topology to

From: Pierre Morel
Subject: Re: [PATCH v11 04/11] s390x/cpu topology: reporting the CPU topology to the guest
Date: Tue, 22 Nov 2022 10:05:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0

On 11/21/22 15:13, Cédric Le Goater wrote:
+static char *s390_top_set_level2(S390Topology *topo, char *p)
+    int i, origin;
+    for (i = 0; i < topo->nr_sockets; i++) {
+        if (!topo->socket[i].active_count) {
+            continue;
+        }
+        p = fill_container(p, 1, i);
+        for (origin = 0; origin < S390_TOPOLOGY_MAX_ORIGIN; origin++) {
+            uint64_t mask = 0L;
+            mask = topo->socket[i].mask[origin];
+            if (mask) {
+                p = fill_tle_cpu(p, mask, origin);
+            }
+        }
+    }
+    return p;

Why is it not possible to compute this topo information at "runtime",
when stsi is called, without maintaining state in an extra S390Topology
object ? Couldn't we loop on the CPU list to gather the topology bits
for the same result ?

It would greatly simplify the feature.


The vCPU are not stored in order of creation in the CPU list and not in a topology order. To be able to build the SYSIB we need an intermediate structure to reorder the CPUs per container.

We can do this re-ordering during the STSI interception but the idea was to keep this instruction as fast as possible.> The second reason is to have a structure ready for the QEMU migration when we introduce vCPU migration from a socket to another socket, having then a different internal representation of the topology.

However, if as discussed yesterday we use a new cpu flag we would not need any special migration structure in the current series.

So it only stays the first reason to do the re-ordering preparation during the plugging of a vCPU, to optimize the STSI instruction.

If we think the optimization is not worth it or do not bring enough to be consider, we can do everything during the STSI interception.

Is it called on a hot code path ? AFAICT, it is only called once
per cpu when started. insert_stsi_3_2_2 is also a guest exit andit queries the machine definition in a very similar way.

It is not fully exact, stsi(15) is called at several moments, not only on CPU creation, but each time the core calls rebuild_sched_domains() that is for s390 on:
- change in the host topology
- changes in CPUSET: for allowed CPU or load balancing




Pierre Morel
IBM Lab Boeblingen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]