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<anth...@codemonkey.ws> writes: > > > >>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 :-) > > > >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