[Top][All Lists]

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

Re: [PATCH v15 00/11] s390x: CPU Topology

From: Pierre Morel
Subject: Re: [PATCH v15 00/11] s390x: CPU Topology
Date: Fri, 10 Feb 2023 14:23:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

On 2/9/23 18:14, Nina Schoetterl-Glausch wrote:
IMO this series looks good overall and like it's nearing the final stages.

Thank you for your helping this.

You use "polarity" instead of "polarization" a lot.
Since the PoP uses polarization I think that term would be preferred.


With the series as it is, one cannot set the polarization via qmp,
only the entitlement of individual cpus. So only the VM can change
the polarization.
Would it be desirable to also be able to set the polarization from the outside?

I do not think so, AFAIK this is not foreseen by the architecture.
My point of view on this is that the application running on the guest is the one knowing if it can get use of the heterogeneous CPU provisioning provided by the vertical polarization or not. Horizontal polarization being the default with an homogeneous, or considered as default, provisioning.

Like I said in one response, it would be good to consider if we need an
polarization_change_in_progress state that refuses requests.
I'm guessing not, if a request is always completed before the next is handled
and there is no way to lose requests.
I don't know how long it would take to change the CPU assignment and if there
is a chance that could be overwhelmed by too many requests.
Probably not but something worth thinking about.

Currently, guest request for a topology change is done via the sysfs interface by a userland process. The value returned by the kernel to userland is -BUSY, for both DONE and IN_PROGRESS. So at first sight I do not see a overwhelming problem but having a completion indication looks like a good thing to have in a future extension in both QEMU and Kernel

Might be a good idea to add a test case that performs test via qmp.
So starts an instance with some cpu topology assignments, checks that
qmp returns the correct topology, hot plugs a cpu and does another check,
Changes topology attributes, etc.
I guess this would be an avocado test.

Yes you are right there is a lot to test.
There is already a test for kvm_unit_tests in review to test PTF and STSI instruction's interception. We do not use avocado as far as I know but our hades tests framework for the kind of tests you propose. I never used avocado for now but at first sight, avocado and hades look similar.


Pierre Morel
IBM Lab Boeblingen

reply via email to

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