From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ1Wf-0003c5-Su for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:29:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ1WZ-0000cH-Hl for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:29:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ1WZ-0000c3-97 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:29:03 -0400 Message-ID: <1378733344.3072.58.camel@localhost.localdomain> From: Marcel Apfelbaum Date: Mon, 09 Sep 2013 16:29:04 +0300 In-Reply-To: References: <1378725114-13197-1-git-send-email-marcel.a@redhat.com> <1378725114-13197-3-git-send-email-marcel.a@redhat.com> <20130909114029.GB31476@redhat.com> <1378728715.3072.14.camel@localhost.localdomain> <20130909122307.GB583@redhat.com> <1378730629.3072.32.camel@localhost.localdomain> <20130909125914.GA1052@redhat.com> <1378732537.3072.49.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Anthony Liguori , Jan Kiszka , QEMU Developers , "Michael S. Tsirkin" On Mon, 2013-09-09 at 14:19 +0100, Peter Maydell wrote: > On 9 September 2013 14:15, Marcel Apfelbaum wrote: > > On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote: > >> Can you just pick the device which is (a subclass of) > >> TYPE_PCI_HOST_BRIDGE, or do we have host bridges which > >> aren't using that class? > > This is what I would really want to do, but some HOST Bridge devices > > inherit directly from PCI_DEVICE. > > > TYPE_PCI_HOST_BRIDGE derives from TYPE_SYS_BUS_DEVICE which > > is a not a PCI device and does not help us here (not a PCI_DEVICE > > on the bus) > > Oops, yes, I get those two the wrong way round a lot. Anyway, > if we need to make all host bridges have a common subclass > we could certainly refactor them accordingly. > > > Strangely TYPE_Q35_HOST_DEVICE derives from TYPE_SYS_BUS_DEVICE > > and it hold as composition a PCIDevice that will be part of > > the bus, as opposed to TYPE_I440FX_PCI_DEVICE which directly > > inherits from PCI_DEVICE. > > This may just be wrong choice of name rather than actually > wrong hierarchy. I try not to "judge" the naming convention, so let's leave it aside for now. My issue is that we have at least 2 ways to model the bridges: 1. TYPE_PCI_HOST_BRIDGE * derives from TYPE_SYS_BUS_DEVICE * has a bus * one of the bus devices is a TYPE_I440FX_PCI_DEVICE which derives from TYPE_PCI_DEVICE 2. TYPE_PCIE_HOST_BRIDGE * derives from TYPE_PCI_HOST_BRIDGE which derives from TYPE_SYS_BUS_DEVICE * has a PciDevice and register it to the bus in order to work as (1) I would like to implement an hierarchy that will allow all the host bridge devices to have a common ancestor In this was, we can scan the PCI bus to look for master... > > -- PMM