From: Marcel Apfelbaum <marcel.a@redhat.com>
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>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses
Date: Mon, 09 Sep 2013 16:15:37 +0300 [thread overview]
Message-ID: <1378732537.3072.49.camel@localhost.localdomain> (raw)
In-Reply-To: <CAFEAcA_AnnitjLwHvfRUceP6KvaDyz394fQMTBQ7ETXOY1w7tA@mail.gmail.com>
On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote:
> On 9 September 2013 13:59, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Sep 09, 2013 at 01:52:11PM +0100, Peter Maydell wrote:
> >> 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.
>
> > Yes. As a shortcut, what I suggest is registering the
> > device that wants to be notified of master aborts with
> > the bus.
>
> 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)
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.
It seems to me as a dead end, or we need to re-factor the current
hierarchy.
Marcel
>
> -- PMM
next prev parent reply other threads:[~2013-09-09 13:15 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-09 11:11 [Qemu-devel] [PATCH RFC v2 0/3] pci: complete master abort protocol Marcel Apfelbaum
2013-09-09 11:11 ` [Qemu-devel] [PATCH RFC v2 1/2] memory: allow MemoryRegion's priority field to accept negative values Marcel Apfelbaum
2013-09-09 11:28 ` Peter Maydell
2013-09-09 12:03 ` Marcel Apfelbaum
2013-09-09 11:11 ` [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses Marcel Apfelbaum
2013-09-09 11:40 ` Michael S. Tsirkin
2013-09-09 12:11 ` Marcel Apfelbaum
2013-09-09 12:23 ` Michael S. Tsirkin
2013-09-09 12:43 ` Marcel Apfelbaum
2013-09-09 12:52 ` Peter Maydell
2013-09-09 12:59 ` Michael S. Tsirkin
2013-09-09 13:02 ` Peter Maydell
2013-09-09 13:15 ` Marcel Apfelbaum [this message]
2013-09-09 13:19 ` Peter Maydell
2013-09-09 13:29 ` Marcel Apfelbaum
2013-09-09 13:39 ` Peter Maydell
2013-09-09 14:04 ` Marcel Apfelbaum
2013-09-09 14:21 ` Peter Maydell
2013-09-09 14:51 ` Marcel Apfelbaum
2013-09-09 14:58 ` Peter Maydell
2013-09-09 16:00 ` Michael S. Tsirkin
2013-09-09 16:02 ` Peter Maydell
2013-09-09 16:34 ` Michael S. Tsirkin
2013-09-09 16:54 ` Jan Kiszka
2013-09-09 16:58 ` Peter Maydell
2013-09-09 17:09 ` Jan Kiszka
2013-09-09 17:14 ` Peter Maydell
2013-09-09 17:27 ` Jan Kiszka
2013-09-09 17:37 ` Michael S. Tsirkin
2013-09-09 17:41 ` Peter Maydell
2013-09-09 18:06 ` Jan Kiszka
2013-09-09 18:11 ` Paolo Bonzini
2013-09-09 19:35 ` Michael S. Tsirkin
2013-09-09 18:03 ` Paolo Bonzini
2013-09-09 18:49 ` Jan Kiszka
2013-09-09 18:59 ` Peter Maydell
2013-09-09 19:04 ` Jan Kiszka
2013-09-09 19:27 ` Michael S. Tsirkin
2013-09-09 19:31 ` Michael S. Tsirkin
2013-09-09 15:54 ` Michael S. Tsirkin
2013-09-09 14:04 ` Michael S. Tsirkin
2013-09-09 14:16 ` Marcel Apfelbaum
2013-09-09 13:59 ` Michael S. Tsirkin
2013-09-09 13:07 ` Marcel Apfelbaum
2013-09-09 13:16 ` Peter Maydell
2013-09-09 13:44 ` Marcel Apfelbaum
2013-09-10 12:39 ` Michael S. Tsirkin
2013-09-10 12:50 ` Peter Maydell
2013-09-10 13:02 ` Michael S. Tsirkin
2013-09-10 13:12 ` Peter Maydell
2013-09-10 14:11 ` Michael S. Tsirkin
2013-09-15 7:14 ` Michael S. Tsirkin
2013-09-15 10:56 ` Peter Maydell
2013-09-15 11:05 ` Michael S. Tsirkin
2013-09-15 11:23 ` Peter Maydell
2013-09-15 12:17 ` Michael S. Tsirkin
2013-09-15 13:24 ` Peter Maydell
2013-09-15 13:39 ` Michael S. Tsirkin
2013-09-15 13:49 ` Peter Maydell
2013-09-15 14:08 ` Michael S. Tsirkin
2013-09-15 14:08 ` Peter Maydell
2013-09-15 14:20 ` Michael S. Tsirkin
2013-09-15 14:49 ` Peter Maydell
2013-09-15 15:05 ` Michael S. Tsirkin
2013-09-15 15:08 ` Peter Maydell
2013-09-15 15:31 ` Michael S. Tsirkin
2013-09-15 17:12 ` Peter Maydell
2013-09-15 9:29 ` Marcel Apfelbaum
2013-09-09 14:01 ` Michael S. Tsirkin
2013-09-09 13:58 ` Michael S. Tsirkin
2013-09-09 14:10 ` Marcel Apfelbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1378732537.3072.49.camel@localhost.localdomain \
--to=marcel.a@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.