On Thu, Aug 19, 2010 at 8:49 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 08/19/2010 03:09 PM, Blue Swirl wrote: >> >> On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori<anth...@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. >> > > Should CPUs appear in the QEMU device tree?
They have several properties that should be user visible. >>> 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. Or all buses should be unified, so all devices could be wired into any board. >> 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. IIRC I tried also that approach when I worked on this patch set but there were some problems. Maybe with header file conflicts, or qemu_irq was not available to CPU code. >>> 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. Perhaps the hotplugging system in QEMU needs some rethinking instead. Many real devices are not hot pluggable. >>> 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. What about 486? Or 82489? > It's like modelling a TLB as a > separate device. That has surely happened in ancient times.
