From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfaoF-0007N0-Vt for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:59:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfaoE-0006ur-3Q for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:59:47 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:57266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfaoD-0006uN-U2 for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:59:46 -0400 Received: by dadn2 with SMTP id n2so3446895dad.4 for ; Fri, 15 Jun 2012 10:59:44 -0700 (PDT) Message-ID: <4FDB780D.7070103@codemonkey.ws> Date: Fri, 15 Jun 2012 12:59:41 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120614195458.GB8244@redhat.com> <4FDA4683.6050809@codemonkey.ws> <20120615175700.GD8244@redhat.com> In-Reply-To: <20120615175700.GD8244@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: yamahata@valinux.co.jp, alex.williamson@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, jan.kiszka@siemens.com 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. Regards, Anthony Liguori > > > >> You can hack things together to work without this, but the result is >> unmaintainable spaghetti (which is pretty close to what we already >> have today). >> >> Once the QOM bus support gets merged, I'm going to send out an ISA >> bus refactoring which gets most of the platform devices away from >> ISA.. >> >> Regards, >> >> Anthony Liguori >>