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

[Avi Kivity <avi@redhat.com>]

  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