From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URkaV-00008L-Sf for qemu-devel@nongnu.org; Mon, 15 Apr 2013 10:40:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URkaU-0000qy-27 for qemu-devel@nongnu.org; Mon, 15 Apr 2013 10:40:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URkaT-0000qq-PW for qemu-devel@nongnu.org; Mon, 15 Apr 2013 10:40:53 -0400 Date: Mon, 15 Apr 2013 16:34:41 +0200 From: Igor Mammedov Message-ID: <20130415163441.7cf6e6e1@nial.usersys.redhat.com> In-Reply-To: <20130415134524.GB2719@otherpad.lan.raisama.net> References: <1365691918-30594-1-git-send-email-imammedo@redhat.com> <1365691918-30594-12-git-send-email-imammedo@redhat.com> <20130411191233.GM6862@otherpad.lan.raisama.net> <20130412122045.76e99a85@thinkpad> <20130412131313.GQ2719@otherpad.lan.raisama.net> <20130412174642.1eca8460@thinkpad> <20130412162940.GV2719@otherpad.lan.raisama.net> <20130415153700.60ad49f6@nial.usersys.redhat.com> <20130415134524.GB2719@otherpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/19] target-i386: introduce apic-id property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: aliguori@us.ibm.com, claudio.fontana@huawei.com, qemu-devel@nongnu.org, aderumier@odiso.com, lcapitulino@redhat.com, jfrei@linux.vnet.ibm.com, yang.z.zhang@intel.com, pbonzini@redhat.com, afaerber@suse.de, lig.fnst@cn.fujitsu.com, rth@twiddle.net On Mon, 15 Apr 2013 10:45:24 -0300 Eduardo Habkost 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.