From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
Paul Brook <paul@codesourcery.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
Date: Mon, 19 Jan 2009 13:15:32 -0600 [thread overview]
Message-ID: <4974D154.5010601@codemonkey.ws> (raw)
In-Reply-To: <4974ACD0.601@redhat.com>
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Paul Brook wrote:
>>> It looks like what you're actually doing is pushing the bounce
>>> buffer allocation into the individual packet consumers.
>>>
>>> Maybe a solution to this is a 'do IO on IOVEC' actor, with an
>>> additional flag that says whether it is acceptable to split the
>>> allocation. That way both block and packet interfaces use the same
>>> API, and avoids proliferation of manual bounce buffers in packet
>>> devices.
>>>
>>
>> I think there may be utility in having packet devices provide the
>> bounce buffers, in which case, you could probably unique both into a
>> single function with a flag. But why not just have two separate
>> functions?
>>
>> Those two functions can live in exec.c too. The nice thing about
>> using map() is that it's easily overriden and chained. So what I'm
>> proposing.
>>
>> cpu_physical_memory_map()
>> cpu_physical_memory_unmap()
>
> This should be the baseline API with the rest using it.
Yup.
>> do_streaming_IO(map, unmap, ioworker, opaque);
>
> Why pass map and unmap?
Because we'll eventually have:
pci_device_memory_map()
pci_device_memory_unmap()
In the simplest case, pci_device_memory_map() just calls
cpu_physical_memory_map(). But it may do other things.
> grant based devices needn't go through this at all, since you never
> mix grants and physical addresses, and since grants never need bouncing.
So the grant map/unmap function doesn't need to deal with calling
cpu_physical_memory_map/unmap. You could still use the above API or
not. It's hard to say.
>> do_packet_IO(map, unmap, buffer, size, ioworker, opaque);
>
> If you pass the buffer then the device needs to allocate large amounts
> of bounce memory.
If do_packet_IO took a buffer, instead of calling alloc_buffer(size)
when map fails (you run out of bounce memory), you simply use buffer.
Otherwise, alloc_buffer() must be able to allocate enough memory to
satisfy any request.
Since each packet device knows it's maximum size up front, it makes
sense for the device to allocate it. You could also not care and just
trust that callers do the right thing.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2009-01-19 19:15 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
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 [this message]
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=4974D154.5010601@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Ian.Jackson@eu.citrix.com \
--cc=avi@redhat.com \
--cc=paul@codesourcery.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).