qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
Date: Tue, 20 Jan 2009 12:09:44 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Anthony Liguori wrote:
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.

Let's start without those callbacks, until those "other things" reveal themselves.

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.


Pushing things to the caller complicates all callers. This isn't the ideal solution.

--
error compiling committee.c: too many arguments to function





reply via email to

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