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

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/19/2010 03:09 PM, Blue Swirl wrote:
> 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.
>    

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