From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfanD-0005pD-UB for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:58:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfanB-0006PZ-PG for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:58:43 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:44404) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfanB-0006NT-IR for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:58:41 -0400 Received: by pbbro12 with SMTP id ro12so5849419pbb.4 for ; Fri, 15 Jun 2012 10:58:39 -0700 (PDT) Message-ID: <4FDB77C9.6020901@codemonkey.ws> Date: Fri, 15 Jun 2012 12:58:33 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120614195458.GB8244@redhat.com> <4FDA4683.6050809@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/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 :-) 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. 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. 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. Regards, Anthony Liguori > > [...]