From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgd6m-0003FY-Ik for qemu-devel@nongnu.org; Mon, 18 Jun 2012 10:39:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sgd6b-0005My-SF for qemu-devel@nongnu.org; Mon, 18 Jun 2012 10:39:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgd6b-0005Kr-L4 for qemu-devel@nongnu.org; Mon, 18 Jun 2012 10:39:01 -0400 Date: Mon, 18 Jun 2012 17:38:55 +0300 From: "Michael S. Tsirkin" Message-ID: <20120618143855.GD26540@redhat.com> References: <20120614195458.GB8244@redhat.com> <4FDA4683.6050809@codemonkey.ws> <20120615175700.GD8244@redhat.com> <4FDB780D.7070103@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] q35 chipset support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: jan.kiszka@siemens.com, Jason Baron , qemu-devel@nongnu.org, yamahata@valinux.co.jp, alex.williamson@redhat.com, Anthony Liguori On Mon, Jun 18, 2012 at 03:52:34PM +0200, Markus Armbruster wrote: > Anthony Liguori writes: > > > On 06/15/2012 12:57 PM, Jason Baron wrote: > >> On Thu, Jun 14, 2012 at 03:16:03PM -0500, Anthony Liguori wrote: > >>> 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. > >>> > >> > >> Right, there is no h/w isa bus, but the LPC interface chip is modeled as an isa > >> bridge. So having an isa bus hanging off of it doesn't seem unreasonable. Unless > >> there is some more fundamental reason not do it this way? > >> > >> It hows up in lspci as: > >> > >> 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface > >> Controller (rev 02) > > > > It's not a question of ISA vs. LPC, it's which devices are actually on > > that bus. See my respond to Markus's note. > > Maybe I'm naive, but platform devices handing off an ISA bus provided by > that ICH9 ISA bridge looks like a fair approximation to me. Yes, the > actual wiring is LPC, but that's a hardware detail invisible to device > models and guest, isn't it? > > Of course, you can't connect anything but the platform devices to that > bus. To connect other ISA devices, you'd have to add a second ISA > bridge. I suspect that's what you meant by "You can still have a > PCI-ISA bridge but the SuperI/O chip is not part of it" elsewhere in > this thread. > > No idea whether such beasts exist in the physical world, and how they > work. See a dump from an old machine of mine (thinkpad T500 FWIW): it does have an ISA bridge behind the root bus.