[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 16:15:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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:

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

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.


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.


Anthony Liguori



reply via email to

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