| Message ID | 20230201132051.126868-1-pmorel@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | s390x: CPU Topology | expand |
IMO this series looks good overall and like it's nearing the final stages. 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? 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. 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.
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. OK > > 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. Regards, Pierre