Re: [Qemu-devel] q35 chipset support

[Anthony Liguori]

On 06/18/2012 03:36 PM, Jason Baron wrote:
> On Mon, Jun 18, 2012 at 09:05:17AM -0500, Anthony Liguori wrote:
> > 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 :-)
>
> I'd like to understand this example better.
>
> I see that DMA_init() is called by pc_basic_device_init(), and used by devices
> such as fdc.c and cs4231a.c.

Correct.  It also is not modeled as a device at all (yikes!).

I've got a patch that converts dma.c to QOM actually/

> So, it appears that the DMA controller is currently
> used as an ISA dma controller.

Yes.

> However, I don't see that hw/dma.c has explicit
> ties to the ISA bus modeling.

But there should be.  DMA is a fundamental part of the ISA specification.  The 
ISA DMA interface is the only way that an ISA device can read from physical memory.

> The current code in hw/fdc.c does:
>
> DMA_read_memory (nchan, fdctrl->fifo + rel_pos,
>                  fdctrl->data_pos, len);
>
> And the rest of interfaces to DMA in isa.h are:
>
> /* dma.c */
> int DMA_get_channel_mode (int nchan);
> int DMA_read_memory (int nchan, void *buf, int pos, int size);
> int DMA_write_memory (int nchan, void *buf, int pos, int size);
> void DMA_hold_DREQ (int nchan);
> void DMA_release_DREQ (int nchan);
> void DMA_schedule(int nchan);
>
> So I don't see a requirement that forces things to be an ISA device to
> make use of the DMA controller.

The only way an ISA device can read memory is by using a DMA controller.  We 
cheat in QEMU today but when trying to model an IOMMU, we cannot get away with 
cheating anymore.

Regards,

Anthony Liguori

> Thanks,
>
> -Jason