> > 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
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
> > 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
>
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 e
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 yo
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 j
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.
> > >
>
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 nee
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 add
> 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
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 po
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:/
12 matches
Mail list logo
