[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 1 of 5] fix cpu_physical_memory len
From: |
Andrea Arcangeli |
Subject: |
[Qemu-devel] Re: [PATCH 1 of 5] fix cpu_physical_memory len |
Date: |
Fri, 12 Dec 2008 20:26:46 +0100 |
On Fri, Dec 12, 2008 at 01:06:56PM -0600, Anthony Liguori wrote:
> Andrea Arcangeli wrote:
>> From: Andrea Arcangeli <address@hidden>
>>
>> Be consistent and have length be size_t for all methods.
>>
>
> ram_addr_t would be better than size_t here.
Yes, that is feasible even if the dma api output remains a raw iovec
(as it'll surely bounce, and the bouncing internally can restarts with
unsigned long long length). To explain why it's set to a size_t, it's
just that I didn't think an emulated device would ever attempt a dma
on a >4G region on a 32bit host, and I was suggested to make this
assumption by the current code that can't even handle that on a 64bit
host (I made it possible on a 64bit host, on a 64bit host it makes
some sense as there can really be that much ram allocated). For 32bit
it mostly makes sense for mmio regions but that sounds a real
weirdness to do such a large dma on a mmio region. So I thought
sticking with size_t would less prone for truncation errors and I
could the sanity checking only once (currently you'd get a graceful
driver failure with the submit handler getting an error, if you
attempt that).
But I can change to ram_addr_t if you like. It's up to you!
[Qemu-devel] [PATCH 4 of 5] dma api, Andrea Arcangeli, 2008/12/12
[Qemu-devel] [PATCH 1 of 5] fix cpu_physical_memory len, Andrea Arcangeli, 2008/12/12
[Qemu-devel] [PATCH 3 of 5] rename dma.c to isa_dma.c, Andrea Arcangeli, 2008/12/12