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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On 08/19/2010 04:21 PM, Blue Swirl wrote:
>>> Should CPUs appear in the QEMU device tree?
>>>      
>> They have several properties that should be user visible.
>>    
>
> Sure, but that's an argument for having some of the qdev features
> (like variant properties) be consumable outside of qdev.

While that might be useful, I don't quite see what makes CPUs so special
that they need to be kept out of qdev.  Could be just my ignorance, of
course.

>>> 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.
>
> But that defeats the notion of having bus level interfaces.  You
> really want the virtio PCI layer to only use PCI functions and
> specifically to interact with PCI concepts that don't exist in other
> busses (like IO regions and config space).  However, you also want the
> ability to interact with a virtio device through a well defined
> interface that isn't PCI specific.
>
> The only way to do this right now is having a bus with a single
> device.  I've been working on the serial device, and what this
> requires is having an ISASerialDevice which is-a ISADevice.  The
> ISASerialDevice has-a 
> SerialBus and the SerialBus contain a single SerialDevice which is-a 
> DeviceState.

It needs to be a SerialBusDevice, not just a DeviceState, actually.

> But the ISASerialDevice has to assume that the SerialBus contains only
> a single child because it needs to connect the GPIO out from the
> SerialDevice to the ISA irq that's assigned.
>
> It would be a whole lot simpler to break the "all devices sit on
> busses" assumption that we have today and simply have the
> ISASerialDevice has-a 
> SerialDevice with no additional layers of bus indirection.

What's the *practical* benefit of splitting up ISASerialDevice into
UART-ISA adapter and the UART proper?

The "bus" sitting between the two would be trivial.  If we do that
everywhere, we'll end up with many different, trivial buses.

>> 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.
>>    
>
> Okay, I'll queue it up for a future day.
>
>>> 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.
>>    
>
> That's probably fair.  I don't think hot plugging should exist at the
> qdev level.  Hot plugging is a very bus specific concept with very bus
> specific restrictions.  For instance, with PCI, you can only plug at
> slot granularities whereas today, we don't really model multi-function
> devices as anything more than a set of unrelated devices.  So there's
> really no way you could conceptually hot plug a multi-function virtio
> adapter although you can pretty trivially create one statically.

I think it's fair to say that qdev doesn't currently get hot-plugging
right.

>>>>> 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.

That's a pretty convincing argument for why a LAPIC should not be
separated from its CPU in qdev.  It should be part of the CPU qdev, or
maybe a child of it.

>> What about 486? Or 82489?
>>    
>
> Don't confuse the local APIC with the PIC or the I/O APIC.
>
> The local APIC has always existed in the CPU core.  There is also an
> I/O APIC which exists outside of the CPU core.  The local APIC was
> introduced with SMP support.
>
> The PIC and IO APIC totally make sense to be modelled as qdev.
>
>>>   It's like modelling a TLB as a
>>> separate device.
>>>      
>> That has surely happened in ancient times.
>>    
>
> Yes, but the programming model was different.
>
> Look at the PIC compared to the lapic.  The PIC is programmed via pio
> at a fixed location.  There is only one PIC and it interacts with the
> system just like all other devices.  IOW, there is no reference to
> CPUState.
>
> When you look at the local APIC (apic.c) however, you see that it's
> the only device in the tree that actually interacts with a CPUState.
> The notion of cpu_get_current_apic() is a good example of the tricks
> needed to make this work.
>
> The local APIC is a cpu feature, not a device.

A bit like the UART is a ISASerialDevice feature?