On 08/19/2010 11:49 PM, Anthony Liguori wrote:
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.
I don't think we want to model individual resistors on a serial card as
separate qdev objects. We want the serial card itself to be a qdev (as
it is a hotpluggable entity) and the individual serial interfaces on
that card (as they are duplicates of each other and of interest to the
user).
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 a special case, but nothing is extreme about it. Hardware often
breaks abstraction layers. For example, on newer systems the memory
controller is programmed using MSRs. This affects not just the cpu, but
also devices writing to memory that is attached to that cpu.
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.
Even on PCI, some devices will be hot-pluggable and some won't be.
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.
As was mentioned, all three exist. Some processors had the MMU as a
separate chip. Even the FPU was once a separate chip, so you not only
had instructions reach out to state in another device, you had another
device actually executing instructions on behalf of a cpu.
--
error compiling committee.c: too many arguments to function