Re: [Qemu-devel] q35 chipset support

[Anthony Liguori <anthony@codemonkey.ws>]

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 :-)

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.

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.

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.

Regards,

Anthony Liguori

>
> [...]