From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgjIA-0007Ae-0j for qemu-devel@nongnu.org; Mon, 18 Jun 2012 17:15:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgjI7-0003CV-9d for qemu-devel@nongnu.org; Mon, 18 Jun 2012 17:15:21 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:59835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgjI6-0003BE-VL for qemu-devel@nongnu.org; Mon, 18 Jun 2012 17:15:19 -0400 Received: by pbbro12 with SMTP id ro12so9288770pbb.4 for ; Mon, 18 Jun 2012 14:15:17 -0700 (PDT) Message-ID: <4FDF9A61.2010604@codemonkey.ws> Date: Mon, 18 Jun 2012 16:15:13 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120614195458.GB8244@redhat.com> <4FDA4683.6050809@codemonkey.ws> <4FDB77C9.6020901@codemonkey.ws> <4FDF359D.2090506@codemonkey.ws> <20120618203607.GE12377@redhat.com> In-Reply-To: <20120618203607.GE12377@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] q35 chipset support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Baron Cc: mst@redhat.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org, Markus Armbruster , yamahata@valinux.co.jp, alex.williamson@redhat.com 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 writes: >>> >>>> On 06/15/2012 02:04 AM, Markus Armbruster wrote: >>>>> Anthony Liguori 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