On 06/15/2012 02:04 AM, Markus Armbruster wrote:
Anthony Liguori<anth...@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
[...]
