From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
Date: Mon, 19 Jan 2009 09:39:49 -0600 [thread overview]
Message-ID: <49749EC5.3080704@codemonkey.ws> (raw)
In-Reply-To: <4974943B.4020507@redhat.com>
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
next prev parent reply other threads:[~2009-01-19 15:40 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-18 19:53 [Qemu-devel] [PATCH 0/5] Direct memory access for devices Avi Kivity
2009-01-18 19:53 ` [Qemu-devel] [PATCH 1/5] Add target memory mapping API Avi Kivity
2009-01-19 13:49 ` Ian Jackson
2009-01-19 14:54 ` Avi Kivity
2009-01-19 15:39 ` Anthony Liguori [this message]
2009-01-19 16:18 ` Paul Brook
2009-01-19 16:33 ` Anthony Liguori
2009-01-19 16:39 ` Avi Kivity
2009-01-19 19:15 ` Anthony Liguori
2009-01-20 10:09 ` Avi Kivity
2009-01-19 16:57 ` Ian Jackson
2009-01-19 19:23 ` Anthony Liguori
2009-01-20 10:17 ` Avi Kivity
2009-01-20 14:18 ` Ian Jackson
2009-01-19 16:40 ` Ian Jackson
2009-01-19 17:28 ` Avi Kivity
2009-01-19 17:53 ` Ian Jackson
2009-01-19 18:29 ` Avi Kivity
2009-01-20 14:32 ` Ian Jackson
2009-01-20 17:23 ` Avi Kivity
2009-01-19 18:25 ` Jamie Lokier
2009-01-19 18:43 ` Avi Kivity
2009-01-20 14:49 ` Ian Jackson
2009-01-20 17:42 ` Avi Kivity
2009-01-20 18:08 ` Jamie Lokier
2009-01-20 20:27 ` Avi Kivity
2009-01-21 16:53 ` Ian Jackson
2009-01-21 16:50 ` Ian Jackson
2009-01-21 17:18 ` Avi Kivity
2009-01-21 21:54 ` Anthony Liguori
2009-01-20 14:44 ` Ian Jackson
2009-01-21 12:06 ` [Qemu-devel] " Mike Day
2009-01-21 12:18 ` Avi Kivity
2009-01-19 15:05 ` [Qemu-devel] [PATCH 1/5] " Gerd Hoffmann
2009-01-19 15:23 ` Avi Kivity
2009-01-19 15:29 ` Avi Kivity
2009-01-19 15:57 ` Gerd Hoffmann
2009-01-19 16:25 ` Avi Kivity
2009-01-19 17:08 ` Ian Jackson
2009-01-19 17:16 ` Avi Kivity
2009-01-19 14:56 ` [Qemu-devel] " Anthony Liguori
2009-01-19 15:03 ` Avi Kivity
2009-01-19 15:49 ` Anthony Liguori
2009-01-19 15:51 ` Avi Kivity
2009-01-20 18:43 ` Anthony Liguori
2009-01-21 17:09 ` Ian Jackson
2009-01-21 18:56 ` [Qemu-devel] " Mike Day
2009-01-21 19:35 ` Avi Kivity
2009-01-21 19:36 ` [Qemu-devel] Re: [PATCH 1/5] " Anthony Liguori
2009-01-22 12:18 ` Ian Jackson
2009-01-22 18:46 ` Anthony Liguori
2009-01-26 12:23 ` Ian Jackson
2009-01-26 18:03 ` Anthony Liguori
2009-01-21 11:52 ` [Qemu-devel] " Mike Day
2009-01-21 12:17 ` Avi Kivity
2009-01-21 17:37 ` Paul Brook
2009-01-18 19:53 ` [Qemu-devel] [PATCH 2/5] Add map client retry notification Avi Kivity
2009-01-19 14:58 ` [Qemu-devel] " Anthony Liguori
2009-01-18 19:53 ` [Qemu-devel] [PATCH 3/5] Vectored block device API Avi Kivity
2009-01-19 16:54 ` Blue Swirl
2009-01-19 17:19 ` Avi Kivity
2009-01-18 19:53 ` [Qemu-devel] [PATCH 4/5] I/O vector helpers Avi Kivity
2009-01-18 19:53 ` [Qemu-devel] [PATCH 5/5] Convert IDE to directly access guest memory Avi Kivity
2009-01-19 16:50 ` [Qemu-devel] [PATCH 0/5] Direct memory access for devices Blue Swirl
-- strict thread matches above, loose matches on Subject: below --
2009-01-22 10:36 [Qemu-devel] [PATCH 0/5] Direct memory access for devices (v2) Avi Kivity
2009-01-22 10:36 ` [Qemu-devel] [PATCH 1/5] Add target memory mapping API Avi Kivity
2009-01-22 12:24 ` Ian Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49749EC5.3080704@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Ian.Jackson@eu.citrix.com \
--cc=avi@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).