From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ23L-0008BL-N5 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 10:03:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ23F-000391-Jf for qemu-devel@nongnu.org; Mon, 09 Sep 2013 10:02:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ23F-00038m-9N for qemu-devel@nongnu.org; Mon, 09 Sep 2013 10:02:49 -0400 Date: Mon, 9 Sep 2013 17:04:53 +0300 From: "Michael S. Tsirkin" Message-ID: <20130909140453.GE1052@redhat.com> References: <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> <1378733344.3072.58.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1378733344.3072.58.camel@localhost.localdomain> 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: Marcel Apfelbaum Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , QEMU Developers , Paolo Bonzini On Mon, Sep 09, 2013 at 04:29:04PM +0300, Marcel Apfelbaum wrote: > 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... I wouldn't object to is_host is stuct PCIDeviceClass. That's probably easier that trying to create a common class for devices that share no common code. > > > > > -- PMM >