Re: [Qemu-devel] qemu cpu-all.h exec.c
> > 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. > > Interesting idea, do you mean that all individual bus address spaces > could exist in system view in the same large address space outside the > target CPU address space? Then some of the translations could become > simple offset operations. No, I was basically assuming that all cpu->device mappings are linear offsets. This means you need almost no changes to the current CPU access code. You can also arrange for all device DMA requests to be translated into CPU physical addresses (VIA IOMMU, or whatever), then treat them the same as if they were CPU accesses. However on second thoughts this probably isn't such a clever idea. There are some potentially interesting cases it can't handle. I'll see if I can come up with an actual proposal. My current theory is that we should be able to combine the bus mappings with the TLB fill, which should help mitigate the overhead. Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: > > > 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. The difference between "passive" stacking and "active" should be minimal and not visible to the devices. > > 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. Right, but if we have this "active" stacking, address translation could be a possible future extension of this mode. > 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. Interesting idea, do you mean that all individual bus address spaces could exist in system view in the same large address space outside the target CPU address space? Then some of the translations could become simple offset operations.
Re: [Qemu-devel] qemu cpu-all.h exec.c
> > 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
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/3/08, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > Blue Swirl wrote: > > On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: > >> On Wednesday 02 January 2008, Blue Swirl wrote: > >>> On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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
Re: [Qemu-devel] qemu cpu-all.h exec.c
Blue Swirl wrote: On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: On Wednesday 02 January 2008, Blue Swirl wrote: On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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. Regards, Fabrice.
Re: [Qemu-devel] qemu cpu-all.h exec.c
On Thursday 03 January 2008, Blue Swirl wrote: > On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: > > On Wednesday 02 January 2008, Blue Swirl wrote: > > > On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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? Probably when populating the TLB entry. IIRC by the time we get to the IO callbacks we don't have enough information to generate a CPU exception. > 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. I'm not so sure. RAM is special because it's direct mapped by the TLB rather than going through the (much slower) MMIO handling routines. Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: > On Wednesday 02 January 2008, Blue Swirl wrote: > > On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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.
Re: [Qemu-devel] qemu cpu-all.h exec.c
On Wednesday 02 January 2008, Blue Swirl wrote: > On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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. Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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.
Re: [Qemu-devel] qemu cpu-all.h exec.c
> 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? Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/1/08, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > This patch breaks the behaviour of the memory callbacks if the callbacks > are changed dynamically (see cirrus_update_memory_access() to see what I > mean). You are lucky that no one does that in the subpage case ! I'll change the function pointer to a pointer to function pointer. Also the opaque parameter may need to be different for each function, it just didn't matter for the unassigned memory case.
Re: [Qemu-devel] qemu cpu-all.h exec.c
Blue Swirl wrote: > CVSROOT: /cvsroot/qemu > Module name: qemu > Changes by: Blue Swirl 08/01/01 16:57:19 > > Modified files: > . : cpu-all.h exec.c > > Log message: >Support for registering address space only for some access widths > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.80&r2=1.81 > http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.120&r2=1.121 This patch breaks the behaviour of the memory callbacks if the callbacks are changed dynamically (see cirrus_update_memory_access() to see what I mean). You are lucky that no one does that in the subpage case ! Regards, Fabrice.
