From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36386 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On6dS-00019s-EY for qemu-devel@nongnu.org; Sun, 22 Aug 2010 05:14:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1On6dR-0001Ye-AD for qemu-devel@nongnu.org; Sun, 22 Aug 2010 05:14:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2638) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1On6dR-0001Y4-3L for qemu-devel@nongnu.org; Sun, 22 Aug 2010 05:14:37 -0400 Message-ID: <4C70EA29.4000606@redhat.com> Date: Sun, 22 Aug 2010 12:13:13 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup References: <4C6D86F9.3010602@codemonkey.ws> In-Reply-To: <4C6D86F9.3010602@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , qemu-devel , Paul Brook On 08/19/2010 10:33 PM, Anthony Liguori wrote: > On 06/12/2010 04:14 PM, Blue Swirl wrote: >> Clean up APIC and IOAPIC. Convert both devices to qdev. >> >> v1->v2: >> Remove apic.h reorganization. >> Add IOAPIC and APIC qdev conversions. >> Use CPUState also in 5/7. However on 6/7 we have to again use void * >> because of VMState limitations. VMState gurus, please comment. > > I'm late to the game here, but I'm not sure converting the APIC to > qdev makes a lot of sense conceptually. > > qdev models devices that exist on a bus, but the local APIC actually > lives on the processor core. It's extremely unique in that it > actually maps a physical memory region different depending on the > actual core. It really belongs as part of the CPU emulation and not > as part of the device emulation. The local APIC connects on one side to the processor core, and on the other side to the APIC bus (the system bus on modern processors). > > For now, the practical problem is that you can't hotplug a CPU because > that creates an APIC which lives on the Sysbus which does not allow > hotplug. Making sysbus allow hotplug is definitely note the right > answer though. Why not? > I think the options are to allow non-bus devices (like the APIC) or > make the APIC a special case that's part of the CPU emulation. Every device connects to something else; otherwise you could optimize it out. Currently the "something else" has to be a bus, which to me implies a 1:many connection. Certainly it's true in the case of the APIC or the CPU. -- error compiling committee.c: too many arguments to function