qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 11/19] target-i386: introduce apic-id property


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 11/19] target-i386: introduce apic-id property
Date: Mon, 15 Apr 2013 16:34:41 +0200

On Mon, 15 Apr 2013 10:45:24 -0300
Eduardo Habkost <address@hidden> 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.
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]