[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: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API |
Date: |
Mon, 19 Jan 2009 09:39:49 -0600 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
Avi Kivity wrote:
The interface when cpu_physical_memory_map returns 0 is strange.
Normally everything in qemu is done with completion callbacks, but
here we have a kind of repeated polling.
I agree. This was done at Anthony's request so I'll defer the
response to him.
There are two distinct IO consumers of this API: streaming IO and packet IO.
For streaming IO, you have a model of:
process_data:
while (offset < size) {
data = map(offset, &len)
if (data) {
do IO on (data, len)
unmap(data)
offset += len;
} else
break
}
if (offset < size)
add callback for mappability to process_data
I agree that this model could be formalized into something that took a
'do IO on (data, len)' actor. In fact, since map() and unmap() are
pretty generic, they too could be actors. This would then work for CPU
memory IO, PCI memory IO, etc.
The packet IO API is a bit different. It looks like:
while (offset < size) {
data = map(offset, &len)
if (data == NULL)
break;
sg[n_sg].iov_base = data;
sg[n_sg].iov_len = len;
n_sg++;
offset += len;
}
if (offset < len) {
for (i = 0; i < n_sg; i++)
unmap(sg[i].iov_base);
sg[0].iov_base = alloc_buffer(size);
sg[0].iov_len = size;
cpu_physical_memory_rw(sg[0].iov_base, size);
}
do IO on (sg)
if (offset < len) {
free(sg[0].iov_base);
}
In this case, it isn't useful to get a callback with some of the packet
data. You need to know up front whether you can map all of the packet
data. In fact, a callback API doesn't really work because it implies
that at the end of the callback, you either release the data or that the
next callback could not be invoked until you unmap a previous data.
So this is why I prefer the map() API, as it accommodates two distinct
users in a way that the callback API wouldn't. We can formalize these
idioms into an API, of course.
BTW, to support this model, we have to reserve at least one bounce
buffer for cpu_physical_memory_rw.
Regards,
Anthony Liguori
- [Qemu-devel] [PATCH 0/5] Direct memory access for devices, Avi Kivity, 2009/01/18
- [Qemu-devel] [PATCH 4/5] I/O vector helpers, Avi Kivity, 2009/01/18
- [Qemu-devel] [PATCH 5/5] Convert IDE to directly access guest memory, Avi Kivity, 2009/01/18
- [Qemu-devel] [PATCH 3/5] Vectored block device API, Avi Kivity, 2009/01/18
- [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/18
- 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
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API,
Anthony Liguori <=
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Paul Brook, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Anthony Liguori, 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, Anthony Liguori, 2009/01/19
- 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/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Anthony Liguori, 2009/01/19
- 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/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/19