From: "Blue Swirl" <blauwirbel@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu cpu-all.h exec.c
Date: Thu, 3 Jan 2008 21:44:48 +0200 [thread overview]
Message-ID: <f43fc5580801031144i1e470beeo71cebf689b12c3d6@mail.gmail.com> (raw)
In-Reply-To: <477D1309.6000200@bellard.org>
On 1/3/08, Fabrice Bellard <fabrice@bellard.org> wrote:
> Blue Swirl wrote:
> > On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> >> On Wednesday 02 January 2008, Blue Swirl wrote:
> >>> On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> >>>>> Also the opaque parameter may need to be different for each function,
> >>>>> it just didn't matter for the unassigned memory case.
> >>>> Do you really have systems where independent devices need to respond to
> >>>> different sized accesses to the same address?
> >>> I don't think so. But one day unassigned or even normal RAM memory
> >>> access may need an opaque parameter, so passing the device's opaque to
> >>> unassigned memory handler is wrong.
> >> I'm not convinced. Your current implementation seems to introduce an extra
> >> level of indirection without any plausible benefit.
> >>
> >> If you're treating unassigned memory differently it needs to be handled much
> >> earlier that so you can raise CPU exceptions.
> >
> > Earlier, where's that?
> >
> > Another approach could be conditional stacked handlers, where a higher
> > level handler could pass the access request to lower one (possibly
> > modifying it in flight) or handle completely. Maybe this solves the
> > longstanding generic DMA issue if taken to the device to memory
> > direction.
>
> As I said earlier, the only correct way to handle memory accesses is to
> be able to consider a memory range and its associated I/O callbacks as
> an object which can be installed _and_ removed. It implies that there is
> a priority system close to what you described. It is essential to
> correct long standing PCI bugs for example.
This should be feasible, though raises a few questions. Does this mean
another API for stacked registration, or should stacking happen
automatically with current API? A new function is needed for removal.
What could be the API for setting priorities? How would multiple
layers be enabled for multiple devices at same location? How can a
higher level handler pass the request to lower one? Do we need a
status return for access handler?
A few use cases:
Partial width device > unassigned
ROM > RAM > unassigned
SBus controller > EBus controller > Device > unassigned
Other direction (for future expansion):
Device > DMA controller > SBus controller > IOMMU > RAM > unassigned
next prev parent reply other threads:[~2008-01-03 19:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-01 16:57 [Qemu-devel] qemu cpu-all.h exec.c Blue Swirl
2008-01-01 21:42 ` Fabrice Bellard
2008-01-02 16:42 ` Blue Swirl
2008-01-02 17:18 ` Paul Brook
2008-01-02 17:31 ` Blue Swirl
2008-01-03 1:18 ` Paul Brook
2008-01-03 15:57 ` Blue Swirl
2008-01-03 16:12 ` Paul Brook
2008-01-03 16:53 ` Fabrice Bellard
2008-01-03 19:44 ` Blue Swirl [this message]
2008-01-03 20:16 ` Paul Brook
2008-01-04 20:36 ` Blue Swirl
2008-01-04 22:43 ` Paul Brook
-- strict thread matches above, loose matches on Subject: below --
2007-05-26 17:36 Blue Swirl
2007-04-04 7:55 Jocelyn Mayer
2005-10-30 20:48 Fabrice Bellard
2005-02-10 21:56 Fabrice Bellard
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=f43fc5580801031144i1e470beeo71cebf689b12c3d6@mail.gmail.com \
--to=blauwirbel@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).