From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgcaC-0007yQ-W0 for qemu-devel@nongnu.org; Mon, 18 Jun 2012 10:05:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sgca3-0005Ik-AR for qemu-devel@nongnu.org; Mon, 18 Jun 2012 10:05:32 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:61014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgca3-0005H7-0s for qemu-devel@nongnu.org; Mon, 18 Jun 2012 10:05:23 -0400 Received: by pbbro12 with SMTP id ro12so8797545pbb.4 for ; Mon, 18 Jun 2012 07:05:21 -0700 (PDT) Message-ID: <4FDF359D.2090506@codemonkey.ws> Date: Mon, 18 Jun 2012 09:05:17 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120614195458.GB8244@redhat.com> <4FDA4683.6050809@codemonkey.ws> <4FDB77C9.6020901@codemonkey.ws> In-Reply-To: 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: Markus Armbruster Cc: mst@redhat.com, jan.kiszka@siemens.com, Jason Baron , qemu-devel@nongnu.org, yamahata@valinux.co.jp, alex.williamson@redhat.com 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 :-) > What I don't get is why that connection can't be modelled as an ISA bus. > Provided by a Systembus-ISA bridge if you like. To be clear, it's not LPC vs. ISA. We can't just make all platform devices an X bus device. There's more of a hierarchy and it's guest visible once we throw in an IOMMU capable chipset. Regards, Anthony Liguori >> And because there is an IOMMU, this topology is visible to the guest. >> >> Granted, initial Q35 support won't come with an IOMMU, but we will >> need to do this eventually. There's already non-x86 patches floating >> around. Normally, I would say we should deal with this later when we >> need an IOMMU but part of the reason this is so hard to fix for the PC >> already is the first set of Q35 patches we merged ages ago that >> introduced the silliness of pc_piix.c. The first step in cleaning >> this all up is essentially reverting that first set of patches. >> >> So we need to fix our topological representation of platform devices >> before we start adding more complex chipsets. Otherwise, we're going >> to end up in a bad situation in the near future. > > I'm not sufficiently familiar with the first set of Q35 patches to risk > an opinion here...