From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47912)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1VJ11q-00007e-Ip
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 08:57:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1VJ11j-0007gi-Ae
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 08:57:18 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54836)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1VJ11i-0007gc-Qu
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 08:57:11 -0400
Date: Mon, 9 Sep 2013 15:59:14 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20130909125914.GA1052@redhat.com>
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>
	<CAFEAcA9R9DVVLuP6u9JgxFyAbhTA0XJXfg5iNehiuX=adhTm0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFEAcA9R9DVVLuP6u9JgxFyAbhTA0XJXfg5iNehiuX=adhTm0g@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci
 addresses
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Jan Kiszka <jan.kiszka@siemens.com>, QEMU Developers <qemu-devel@nongnu.org>, Marcel Apfelbaum <marcel.a@redhat.com>

On Mon, Sep 09, 2013 at 01:52:11PM +0100, Peter Maydell wrote:
> On 9 September 2013 13:43, Marcel Apfelbaum <marcel.a@redhat.com> wrote:
> > The scenario is covered only for the primary bus and not for buses
> > behind the PCI bridge (the later being handled differently.)
> > In this case, isn't the Host Bridge always device 00.0?
> 
> No. For instance the host controller may pass a nonzero
> value of devfn_min to pci_bus_new/pci_register_bus (in
> which case the host bridge will end up there; example
> hw/pci-host/versatile.c) or it might just pass a nonzero
> devfn to pci_create_simple when it creates the host controller
> PCI device on the bus (I don't think we have anything that
> does it that way, though).
> 
> > If not, can we find a way to scan all bus devices and find
> > the host bridge so we will not have to manually add it to each
> > host bridge?
> 
> It would be conceptually nicer not to treat host bridges as
> a special case but instead to just report the abort back
> to whatever the PCI master was (which might be a device
> doing DMA). That might be a lot of effort though.
> 
> -- PMM

Yes. As a shortcut, what I suggest is registering the
device that wants to be notified of master aborts with
the bus.

-- 
MST