qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).