From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sge8i-0003kJ-6L for qemu-devel@nongnu.org; Mon, 18 Jun 2012 11:45:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sge8b-00055I-1d for qemu-devel@nongnu.org; Mon, 18 Jun 2012 11:45:15 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:50542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sge8a-00054c-RY for qemu-devel@nongnu.org; Mon, 18 Jun 2012 11:45:08 -0400 Received: by dadn2 with SMTP id n2so6515890dad.4 for ; Mon, 18 Jun 2012 08:45:06 -0700 (PDT) Message-ID: <4FDF4CFF.9040301@codemonkey.ws> Date: Mon, 18 Jun 2012 10:45:03 -0500 From: Anthony Liguori 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> <4FDF4AF2.9020100@suse.de> In-Reply-To: <4FDF4AF2.9020100@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] q35 chipset support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: "Michael S. Tsirkin" , jan.kiszka@siemens.com, Jason Baron , qemu-devel@nongnu.org, Markus Armbruster , yamahata@valinux.co.jp, alex.williamson@redhat.com On 06/18/2012 10:36 AM, Andreas Färber wrote: > 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 merging q35. >> >> 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. All I think is required is that we have the right hiearchy of devices. I don't mind if we're not doing two-stage initialization but we need to make sure the device hierarchy represents what the guest expects to see. Regards, Anthony Liguori > > From what I remember from attempting to refactor the DEC bridge though, > the PCI functions hardcode the domain to 1 currently? > > Andreas >