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

[Blue Swirl <blauwirbel@gmail.com>]

On Thu, Aug 19, 2010 at 8:49 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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?

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.