[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
From: |
Ian Jackson |
Subject: |
Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API |
Date: |
Tue, 20 Jan 2009 14:44:29 +0000 |
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping
API"):
> So wouldn't it be trivial to pass "amount written" to the unmap
> function - to be used in the bounce buffer case?
I think that's probably the best plan. It's certainly a lot simpler
than my most recent proposal.
It seems to me that:
- there has to be a callback mechanism to schedule bounce buffers
- there should be only one control flow
- therefore the interface should always be callback-based
and:
- as Anthony points out, we need to be able to set up for a single-
packet scatter-gather IO
- thus the interface should involve a single request and callback
for a whole DMA scatter gather
This would seem to yield an API that looks roughly like this:
#define CPUPHYSMEMMAPFLAG_READABLE 001
#define CPUPHYSMEMMAPFLAG_WRITABLE 002
#define CPUPHYSMEMMAP_MAX 131072
/* Callers of the mapping API must only request mappings
* totalling this amount or less. Larger requests will
* fail an assertion. */
typedef struct {
target_phys_addr_t addr, len;
} CpuPhysicalMemoryMappingEntry;
/* If requested addresses and lengths are not page-aligned,
* performance will definitely be poor. */
typedef struct {
/* to be filled in by caller before calling _map: */
unsigned flags;
int sg_list_entries;
CpuPhysicalMemoryMappingEntry *sg_list;
/* filled in by _map: */
void *buffer;
/* private to _map et al: */
... some stuff here to actually implement ...
} CpuPhysicalMemoryMapping;
void cpu_physical_memory_map(CpuPhysicalMemoryMapping*,
CpuPhysicalMemoryMapCallback *cb, void *cb_arg);
/* There may be a limit on the number of concurrent maps
* and the limit may be as low as one. */
void cpu_physical_memory_unmap(CpuPhysicalMemoryMapping*,
target_phys_addr_t transferred);
/* For read mappings, transferred is ignored so 0 is OK. */
Ian.
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, (continued)
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Jamie Lokier, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Jamie Lokier, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Anthony Liguori, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API,
Ian Jackson <=
- [Qemu-devel] Re: Add target memory mapping API, Mike Day, 2009/01/21
- Re: [Qemu-devel] Re: Add target memory mapping API, Avi Kivity, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Gerd Hoffmann, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Gerd Hoffmann, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
[Qemu-devel] Re: [PATCH 1/5] Add target memory mapping API, Anthony Liguori, 2009/01/19