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.
