On Mon, Apr 15, 2013 at 03:37:00PM +0200, Igor Mammedov wrote: [...] > > > > ID to be directly specified in the device_add/-device options. That's > > > > how real CPUs work: as the CPU manufacturer doesn't know what will be > > > > the package ID of the CPU, the APIC IDs are not hardcoded in the CPU; > > > > they are calculated based on the CPU topology and some socket identifier > > > > signal coming from the board. > > > that is why apic_id has been made a property, to be set from outside. > > > > True. I believe the conflict here is: we want other objects to set the > > APIC ID (be it the board, or socket/core objects), but at the same time > > it would be interesting to not expose the APIC ID outside QEMU. Being > > too flexible regarding the APIC ID is more likely to cause problems > > later. > > > > That said, I don't mind having a "apic-id" property because it is easier > > to simply expose it directly. But do you agree that: 1) we don't really > > need to expose it to be set from outside QEMU; 2) we shouldn't require > > it to be set from outside QEMU; 3) we should recommend users to not try > > to fiddle it with? > Due to nature of per thread CPU hotplug, management will have to specify some > kind of ID to specify which CPU is being plugged. Management really > doesn't/shouldn't care what this ID is.
As long as management really doesn't/shouldn't care what the ID is, exposing the APIC ID in the form of an opaque CPU identifier wouldn't be a problem to me. I just wanted to make clarify if we agree that messing with the APIC ID directly won't be recommended and that the "apic-id" property will be for QEMU internal use only. -- Eduardo