[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: Mon, 18 Jun 2012 09:05:17 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/18/2012 08:51 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden>  writes:

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.

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.


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...

reply via email to

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