Re: [Qemu-devel] q35 chipset support

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/18/2012 08:51 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@codemonkey.ws>   writes:
>>>
>>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>>> Hi,
>>>>>
>>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>>>> patches that had already been resolved by the current qemu tree.
>>>>>
>>>>> The trees seem pretty stable and can be found here:
>>>>>
>>>>> git://github.com/jibaron/q35-qemu.git
>>>>> git://github.com/jibaron/q35-seabios.git
>>>>
>>>> I'm got the beginnings of a feature page started:
>>>>
>>>> http://wiki.qemu.org/Features/Q35
>>>>
>>>> The approach above will not work in a QOM world unfortunately.  We
>>>> need to do quite a bit of ground work before adding another chipset.
>>>> The biggest task is converting devices to not require an ISA bus since
>>>> ICH9 simply doesn't have an ISA bus.
>>>
>>> Could you explain briefly why use of a software ISA bus construct
>>> matters for device models and/or guests?
>>
>> No, but I can provide a long explanation :-)
>
> Thanks!
>
>> The I440FX has a very basic device topology.  The PCI host is the
>> memory controller and there's a PCI device that happens to have the
>> SuperI/O chip + a PCI-ISA bridge.  There's no IOMMU and interrupt
>> routing is simple.
>
> PC interrupt routing is hardly ever "simple", but I get what you mean ;)
>
>> The Q35 is much more sophisticated.  The PCI-e complex itself can
>> present interesting topologies and the legacy PCI bus sits within the
>> PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
>> chip is not part of it. Rather that's off of a separate bus (the LPC)
>> which does not logically reside within the PCI-e complex.
>
> Let's whether I understand.
>
> The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
> such bridge exists normally).  Instead, they're connected via LPC.

No, *some* platform devices are connected via LPC.  Some are not.

To give you an example: both LPC and ISA provide a bus-level DMA interface. 
When you think of IOMMU modeling, it looks something like this:

Floppy controller:
   isa_memory_read(isa_dev, ...)
    -> talks to DMA controller

DMA controller:
   Implemented in PIIX4 for I440FX, within ICH9 for q35
   Uses cpu_physical_memory_rw() which takes the get_system() MemoryRegion

So we cannot have the DMA controller be a ISA/LPC device as we do today because 
the ISA bus should only use isa_memory_read() which is implemented by the DMA 
controller.  We have an infinite modeling loop today :-)

> What I don't get is why that connection can't be modelled as an ISA bus.
> Provided by a Systembus-ISA bridge if you like.

To be clear, it's not LPC vs. ISA.  We can't just make all platform devices an X 
bus device.  There's more of a hierarchy and it's guest visible once we throw in 
an IOMMU capable chipset.

Regards,

Anthony Liguori

>> And because there is an IOMMU, this topology is visible to the guest.
>>
>> Granted, initial Q35 support won't come with an IOMMU, but we will
>> need to do this eventually.  There's already non-x86 patches floating
>> around.  Normally, I would say we should deal with this later when we
>> need an IOMMU but part of the reason this is so hard to fix for the PC
>> already is the first set of Q35 patches we merged ages ago that
>> introduced the silliness of pc_piix.c.  The first step in cleaning
>> this all up is essentially reverting that first set of patches.
>>
>> So we need to fix our topological representation of platform devices
>> before we start adding more complex chipsets.  Otherwise, we're going
>> to end up in a bad situation in the near future.
>
> I'm not sufficiently familiar with the first set of Q35 patches to risk
> an opinion here...