|
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: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.gitI'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
[Prev in Thread] | Current Thread | [Next in Thread] |