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

[Blue Swirl <blauwirbel@gmail.com>]

On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori <anthony@codemonkey.ws> 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.

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 lives
> on the processor core.  It's extremely unique in that it actually maps 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.

>  It 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 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.

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.