qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu cpu-all.h exec.c


From: Paul Brook
Subject: Re: [Qemu-devel] qemu cpu-all.h exec.c
Date: Thu, 3 Jan 2008 20:16:22 +0000
User-agent: KMail/1.9.7

> > 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 via email to

[Prev in Thread] Current Thread [Next in Thread]