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
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
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
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
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
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
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/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
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
Blue Swirl wrote:
CVSROOT: /cvsroot/qemu
Module name: qemu
Changes by: Blue Swirl blueswir1 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:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 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:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 07/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()
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1 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:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_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:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_mayer 07/04/04 07:55:12
Modified files:
. : cpu-all.h exec.c
Log message:
Add missing 64 bits memory accessors.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 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
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:
17 matches
Mail list logo
