From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sge0M-00088V-0x for qemu-devel@nongnu.org; Mon, 18 Jun 2012 11:36:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sge0G-0002Rq-Ls for qemu-devel@nongnu.org; Mon, 18 Jun 2012 11:36:37 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35198 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sge0G-0002RW-CV for qemu-devel@nongnu.org; Mon, 18 Jun 2012 11:36:32 -0400 Message-ID: <4FDF4AF2.9020100@suse.de> Date: Mon, 18 Jun 2012 17:36:18 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20120614195458.GB8244@redhat.com> <4FDA4683.6050809@codemonkey.ws> <4FDB77C9.6020901@codemonkey.ws> <20120618142043.GA26540@redhat.com> <4FDF39B3.9050806@codemonkey.ws> <20120618143706.GC26540@redhat.com> In-Reply-To: <20120618143706.GC26540@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] q35 chipset support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: jan.kiszka@siemens.com, Jason Baron , qemu-devel@nongnu.org, Markus Armbruster , yamahata@valinux.co.jp, alex.williamson@redhat.com, Anthony Liguori Am 18.06.2012 16:37, schrieb Michael S. Tsirkin: > On Mon, Jun 18, 2012 at 09:22:43AM -0500, Anthony Liguori wrote: >> On 06/18/2012 09:20 AM, Michael S. Tsirkin wrote: >>> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote: >>>> 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. >>> >>> OTOH more in-tree examples especially for x86 will keep us >>> honest: help make sure abstractions make sense, >>> and prevent people from special casing piix because >>> this is the prevalent platform for kvm ATM. >> >> Yes, more in-tree *correct* examples. I'm very much in favor of mergi= ng q35. >=20 > But is there a way to build a correct chipset right now? > Or is this blocked waiting for more infrastructure > to get merged? The qom-next PULL (with QBus type) is out and Anthony has reviewed my pci_host mini-series, those two would be good to have as groundwork. Anything else (e.g., an LPCBus if needed) could be done in the q35 series IIUC. Having q35 modeled with in-place initialization should probably not be a hard requirement, relaxing the PCIBus availability issue. >>From what I remember from attempting to refactor the DEC bridge though, the PCI functions hardcode the domain to 1 currently? Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg