From: Marcel Apfelbaum <marcel.a@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Anthony Liguori <anthony@codemonkey.ws>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] hw/pci: completed master-abort emulation
Date: Tue, 24 Sep 2013 14:17:25 +0300 [thread overview]
Message-ID: <1380021445.2050.99.camel@localhost.localdomain> (raw)
In-Reply-To: <CAFEAcA__hWu8vfidJzL4gMz-mCcJTC0qXYGskNgGv2Qv=dCVQA@mail.gmail.com>
On Tue, 2013-09-24 at 19:55 +0900, Peter Maydell wrote:
> On 24 September 2013 19:44, Marcel Apfelbaum <marcel.a@redhat.com> wrote:
> > We need to check all the bridges on each bus encountered
> > for their address range; if it corresponds to the transaction address,
> > we pass the bridge to the other bus(depending on transaction's direction).
>
> I haven't looked at all at the details, but you can probably rephrase
> this kind of "check address against range and pass recursively
> to other bridge" algorithm in terms of appropriate statically
> constructed memory regions. Since "transaction aborted" is
> definitely not a fast path, the only argument for doing it that way
> would be if the code worked out more neatly -- maybe worth
> thinking about whether it would do so?
I didn't fully understand your comment, please let me explain:
A PCI Device issues a transaction to an unassigned address,
which is in a range corresponding to a bridge on some "upper"
(close to CPU) bus.
The region that will "catch" this access is a background region
"behind" the "target" memory region (bus_master_enable_region).
At this point we know:
1. The PCI device that initiated the transaction
2. The transaction's address
I was suggesting an algorithm to find the MA device in order
to set MA Received Bit in its Status(Sec_Status) register.
The algorithm was to traverse the PCI buses for finding the
MA device using the transaction address.
Marcel
>
> -- PMM
next prev parent reply other threads:[~2013-09-24 11:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 11:01 [Qemu-devel] [PATCH] hw/pci: completed master-abort emulation Marcel Apfelbaum
2013-09-23 11:27 ` Michael S. Tsirkin
2013-09-23 12:37 ` Marcel Apfelbaum
2013-09-23 13:45 ` Michael S. Tsirkin
2013-09-23 14:43 ` Marcel Apfelbaum
2013-09-23 15:10 ` Michael S. Tsirkin
2013-09-23 17:49 ` Marcel Apfelbaum
2013-09-23 18:45 ` Michael S. Tsirkin
2013-09-24 8:07 ` Marcel Apfelbaum
2013-09-24 8:29 ` Michael S. Tsirkin
2013-09-24 8:44 ` Marcel Apfelbaum
2013-09-24 8:58 ` Michael S. Tsirkin
2013-09-24 10:44 ` Marcel Apfelbaum
2013-09-24 10:55 ` Peter Maydell
2013-09-24 11:17 ` Marcel Apfelbaum [this message]
2013-09-24 11:21 ` Peter Maydell
2013-09-24 11:41 ` Marcel Apfelbaum
2013-09-24 15:41 ` Michael S. Tsirkin
2013-09-24 16:24 ` Michael S. Tsirkin
2013-09-24 23:36 ` Peter Maydell
2013-09-24 23:43 ` Michael S. Tsirkin
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=1380021445.2050.99.camel@localhost.localdomain \
--to=marcel.a@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=mst@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.