qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO


From: Andreas Färber
Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Date: Sat, 13 Dec 2008 18:54:21 +0100


Am 13.12.2008 um 17:53 schrieb Andrea Arcangeli:

On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote:
Andrea Arcangeli wrote:
On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote:

void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size,
int is_write);


Just a side note (doesn't mean I agree with the above), it doesn't
make sense to use an ram_addr_t size when you return a 32bit address
on 32bit qemu build.


size_t is completely wrong for 64-bit targets on 32-bit hosts. ram_addr_t is the type we use for guest ram size. It's 64-bit all of the time simply because it's easier to do that and we decided that the little bit of wasted
space/computations were not a problem.

Not sure why you think I'm suggesting you to use size_t. I'm just
trying to tell you that if you insist in this
64bit-guest-on-32bit-host-is-dead-and-obsolete-to-support (i.e. if you
pass a ram_addr_t size to cpu_physical_memory_map) you've at least to
return ram_addr_t too). 'void *' is like size_t so the above API
getting ram_addr_t length and returning 'void *', can't possibly be
sane.

Since memory is allocated on the host with the host's limits, void* seems correct.

That you can't alloc, e.g., 4 GB of size on a 32-bit host is something the DMA API under discussion would need to handle as error. To detect such an attempt, the API needs the guest's data type for the size. :) It would then either assert or return NULL.

Don't forget that this is not only about supposedly "dead" x86 hosts, imagine ppc64 on ppc or amd64 on arm etc.

Andreas





reply via email to

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