[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] q35 chipset support

From: Anthony Liguori
Subject: Re: [Qemu-devel] q35 chipset support
Date: Fri, 15 Jun 2012 12:58:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/15/2012 02:04 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden>  writes:

On 06/14/2012 02:54 PM, Jason Baron wrote:

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:


I'm got the beginnings of a feature page started:


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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]