Re: [Qemu-devel] q35 chipset support

[Anthony Liguori]

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