Re: [Qemu-devel] q35 chipset support

[Jason Baron <jbaron@redhat.com>]

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<anthony@codemonkey.ws>  writes:
> >
> >>On 06/15/2012 02:04 AM, Markus Armbruster wrote:
> >>>Anthony Liguori<anthony@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 :-)
> >
> >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. So, it appears that the DMA controller is currently
used as an ISA dma controller. However, I don't see that hw/dma.c has explicit
ties to the ISA bus modeling. 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.

Thanks,

-Jason