qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Sun, 22 Aug 2010 12:13:13 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1

 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




reply via email to

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