From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58137 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmBUa-0004BH-Nw for qemu-devel@nongnu.org; Thu, 19 Aug 2010 16:13:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmBUZ-0003ju-8D for qemu-devel@nongnu.org; Thu, 19 Aug 2010 16:13:40 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:61903) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmBUY-0003jn-W0 for qemu-devel@nongnu.org; Thu, 19 Aug 2010 16:13:39 -0400 Received: by qwh5 with SMTP id 5so2174604qwh.4 for ; Thu, 19 Aug 2010 13:13:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C6D86F9.3010602@codemonkey.ws> References: <4C6D86F9.3010602@codemonkey.ws> From: Blue Swirl Date: Thu, 19 Aug 2010 20:09:56 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Liu >> \"Liu, Jinsong\"" , Avi Kivity , qemu-devel , Paul Brook On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori wr= ote: > 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. Very late. I think it makes tons of sense, for example with 'info qtree' you now see most of the QEMU devices. The CPUs are still missing. > qdev models devices that exist on a bus, but the local APIC actually live= s > on the processor core. =C2=A0It's extremely unique in that it actually ma= ps a > physical memory region different depending on the actual core. The bus does not need to have any connection to existence or non-existence of real buses. In SoCs or ASICs, all devices and buses may reside inside a chip. For example Sparc32 NCR89C105 contained several devices, all of which are separate in QEMU. If APICs were invented in i386 times, they would be separate chips. In NUMA systems each CPU may see different physical memory layout. But all we care in QEMU is logical entities. > =C2=A0It really > belongs as part of the CPU emulation and not as part of the device > emulation. In that case it should be moved to target-i386. > For now, the practical problem is that you can't hotplug a CPU because th= at > creates an APIC which lives on the Sysbus which does not allow hotplug. > =C2=A0Making sysbus allow hotplug is definitely note the right answer tho= ugh. 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. No. There could also be a new hotpluggable bus type, CPUBus, one instance between each CPU and APIC. Or SysBusWithHotPlug. But I don't see how that would be different from SysBus.