On Mon, 15 Apr 2013 11:49:40 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Mon, Apr 15, 2013 at 04:34:41PM +0200, Igor Mammedov wrote: > > On Mon, 15 Apr 2013 10:45:24 -0300 > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > 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. > > On contrary, it's useful external feature, x86 guests see only APIC ID, > > since > > it's the only ID they [should] know about. So guest aware mgmt could > > definitely use apic_id propery to correlate CPU in guest with QEMU view of > > them. > > You're right, _reading_ the APIC ID is very useful. I am worried about > _setting_ it from external code. currently it's not possible since cpu-add doesn't allow to set any properties. We will need setting it for device_add though. By then, I guess some way to check that it's valid would be enough, otherwise hot-plugged CPU will be out of scope of MADT and guest would ignore it or through an error. > > -- > Eduardo > -- Regards, Igor