> > 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:/
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/qe
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/12 01:16:24
Modified files:
. : cpu-all.h exec.c
linux-user : mmap.c
Log message:
Mark host pages as reserved (Magnus Damm).
CVSWeb URLs:
http://cvs.savanna
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/14 10:51:01
Modified files:
. : cpu-all.h exec.c
linux-user : qemu.h syscall.c
Log message:
suppressed page_unprotect_range() - fixed access_ok()
CVSWeb URLs
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/11/02 19:02:07
Modified files:
. : cpu-all.h exec.c
linux-user : qemu.h
Log message:
EFAULT - verify pages are in cache and are read/write, by Thayne
Harbaugh.
CVS
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/05/26 17:36:03
Modified files:
. : cpu-all.h exec.c
Log message:
Implement generic sub-page I/O based on earlier work by J. Mayer.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qem
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/04/07 11:21:28
Modified files:
. : cpu-all.h exec.c
target-alpha : helper.c
target-arm : helper.c
target-i386: helper2.c
target-m68k: translat
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/04/04 07:55:12
Modified files:
. : cpu-all.h exec.c
Log message:
Add missing 64 bits memory accessors.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/02/28 20:20:53
Modified files:
. : cpu-all.h exec.c
linux-user : syscall.c
Log message:
Fix CPU chaining in linux-user emulation, by Gwenole Beauchesne.
CVSWeb URLs
CVSROOT:/cvsroot/qemu
Module name:qemu
Branch:
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 05/10/30 20:48:42
Modified files:
. : cpu-all.h exec.c
Log message:
more physical memory access functions
CVSWeb URLs:
http://savannah.gnu.org
21 matches
Mail list logo
