|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup |
Date: | Thu, 19 Aug 2010 15:49:43 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 08/19/2010 03:09 PM, Blue Swirl wrote:
On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori<address@hidden> 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.
Should CPUs appear in the QEMU device tree?
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.
Well, I think this is part of the trouble with the current qdev object model. There are really two distinct types of devices. There are chips that have pins whereas the meaning of those pins are defined by the chip itself. For instance, a UART16650A is a chip that has a well defined pin layout.
Then there are buses which typically multiplex signals for many devices over a single set of wires. Usually you need some type of logic that decodes the bus signals to the actual chips that sit on the card.
So really, I think this suggests that some devices shouldn't have any requirement to sit on a bus. A UART16650A does not sit on bus. It sits on a card and is wired to the ISA bus or is sometimes wired directly to pins on a CPU on a SoC.
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.
The local APIC is an extreme special case. There are special CPU instructions that return registers from the APIC (cr8 is the APIC TPR).
It's really part of the core and if there aren't objections, I'd like to move it to target-i386.
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?
Because not all devices on the sysbus can be hot added so if you made the bus hotpluggable, it would basically defeat the point of even marking a bus as not supporting hot plug.
IOW, the whole bus is either hot pluggable or not. You cannot just say that device X can be hotplugged but nothing else.
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.
Neither approach maps well to real hardware. An x86 CPU cannot exist without a local APIC and a local APIC cannot exist without an x86 CPU. The two are fundamentally tied together. It's like modelling a TLB as a separate device.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |