Re: [PATCH v4 2/4] hw/i386: Attach CPUs to machine

On Mon, Feb 07, 2022 at 10:18:43 +0100, Igor Mammedov wrote: > On Mon, 7 Feb 2022 09:14:37 +0100 > Igor Mammedov <imammedo(a)redhat.com&gt; wrote: > > > On Sat, 5 Feb 2022 13:45:24 +0100 > > Philippe Mathieu-Daudé <f4bug(a)amsat.org&gt; wrote: > > > > > Previously CPUs were exposed in the QOM tree at a path > > > > > > /machine/unattached/device[nn] > > > > > > where the 'nn' of the first CPU is usually zero, but can > > > vary depending on what devices were already created. > > > > > > With this change the CPUs are now at > > > > > > /machine/cpu[nn] > > > > > > where the 'nn' of the first CPU is always zero. > > > > Could you add to commit message the reason behind the change? > > regardless, it looks like unwarranted movement to me > prompted by livirt accessing/expecting a QOM patch which is > not stable ABI. I'd rather get it fixed on libvirt side. > > If libvirt needs for some reason access a CPU instance, > it should use @query-hotpluggable-cpus to get a list of CPUs > (which includes QOM path of already present CPUs) instead of > hard-codding some 'well-known' path as there is no any guarantee > that it will stay stable whatsoever. I don't disagree with you about the use of hardcoded path, but the way of using @query-hotpluggable-cpus is not really aligning well for how it's being used. To shed a bit more light, libvirt uses the following hardcoded path #define QOM_CPU_PATH "/machine/unattached/device[0]" in code which is used to query CPU flags. That code doesn't care at all which cpus are present but wants to get any of them. So yes, calling query-hotpluggable-cpus is possible but a bit pointless. In general the code probing cpu flags via qom-get is very cumbersome as it ends up doing ~400 QMP calls at startup of a VM in cases when we deem it necessary to probe the cpu fully.