[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] Add map client retry notification

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/5] Add map client retry notification
Date: Thu, 22 Jan 2009 12:51:29 -0600
User-agent: Thunderbird (X11/20090105)

Ian Jackson wrote:
Avi Kivity writes ("[Qemu-devel] [PATCH 2/5] Add map client retry 
The target memory mapping API may fail if the bounce buffer resources
are exhausted.  Add a notification mechanism to allow clients to retry
the mapping operation when resources become available again.

Does this API not suffer from the potential deadlock described by
Anthony ?

Imagine that for some reason bounce buffers are in use.  If we have a
client which wants to do a single writev on a tap device it will even
deadlock by itself:

  map(<block 0>) succeeds
  map(<block 1>) fails, NULL

but the callback will never happen because the client is effectively
waiting for itself to release its own mapping.

Yes, a client is not allowed to do this. To put it another way (and perhaps this needs to be documented), register_map_client can only be used safely if a client unmaps all of it's existing mappings.

Since callers cannot assume that they can map more than one range at
once (since there's only one bounce buffer), any caller which needs to
do scatter-gather (like a tap device, as Anthony points out) needs to
invent its own bounce buffers.  That seems like a waste of effort.

It needs to be able to fall back to something like cpu_physical_memory_rw.

There should be a single bounce buffer fallback mechanism, and it
should be sufficiently powerful that it can be used for tap devices,
which means that the calling device emulation must present a single
scatter-gather list to the API all in one go.

You could have an API like:

try_to_map_or_bounce(list-of-phys-iovecs, buffer-to-bounce-to, callback, opaque);

That would be a nice addition for packet IO devices. Better yet, it should be:

try_to_map_or_bounce(map-func, unmap-func, iofunc, opaque, list-of-phys-iovecs, buffer-to-bounce-to)

If you go back and look at my previous mails about packet helpers and stream helpers, that's just about the signature of my proposed packet helper. Like I mentioned earlier, I definitely think we should have such a thing.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]