qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] qemu cpu-all.h exec.c
Date: Thu, 3 Jan 2008 20:16:22 +0000	[thread overview]
Message-ID: <200801032016.22922.paul@codesourcery.com> (raw)
In-Reply-To: <f43fc5580801031144i1e470beeo71cebf689b12c3d6@mail.gmail.com>

> > 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?

I don't think "passing through" requests to the next handler is an interesting 
use case.  Just consider a device to handle all accesses within its defined 
region.

If an overlapping region is accessed then at best you're into highly machine 
dependent behavior. The only interesting case I can think of is x86 where a 
PCI region may be overlayed on top of RAM. A single level of priority 
(ram/rom vs. everything else) is probably sufficient for practical purposes.

The most important thing is that when one of the mappings is removed, 
subsequent accesses to the previously overlapped region hit the remaining 
device.

> 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

I think these are different things:

- Registering multiple devices within the same address space.
- Mapping access from one address sapce to annother.

Currently qemu does neither.

The former is what Fabrice is talking about.

The latter depends how general you want the solution to be. One possibility is 
for the device DMA+registration routines map everything onto CPU address 
space.

Paul

  reply	other threads:[~2008-01-03 20:16 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
2008-01-03 20:16                 ` Paul Brook [this message]
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=200801032016.22922.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=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).