On Tue, Apr 16, 2013 at 11:43:42AM +0200, Igor Mammedov wrote:
[...]
> BTW:
> You were advocating using APIC ID on device_add to identify CPU but Eduardo
> would like avoid its usage on external interfaces.
> It would be nice to have your opinion on subject.
> relevant discussion threads are here:
> 1. http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02205.html
> 2. http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02274.html
Trying to summarize my concerns quickly:
0) APIC IDs must be calculated by QEMU based on CPU topology and can't
be chosen arbitrarily.
1) Requiring APIC ID as the CPU ID requires a target-independent
probing interface to find out which IDs are valid, and how they
correspond to locations in the CPU topology. We don't have such
interface yet.
* This makes it impossible to use APIC IDs to identify CPUs in the
command-line (before QMP is available), so we still need another
kind of identifier (topology-based, probably).
2) apic-id is not compatible with the existing IDs used for the "-numa"
command-line option.
So, using APIC ID is possible, but I believe it introduces too much
unnecessary complexity in the external interface. The day we introduce a
full socket/core/thread-based device_add interface, setting APIC ID
directly externally won't be necessary anymore (QEMU could calculate it
based on the object topology), but while we don't have the full-featured
core/socket/thread-based interface we can simply use IDs in the range
[0..(max_cpus-1)], that are already used by the "-numa" command-line
option.
--
Eduardo
