On Fri, Dec 12, 2008 at 01:06:56PM -0600, Anthony Liguori wrote: > Andrea Arcangeli wrote: >> From: Andrea Arcangeli <[email protected]> >> >> 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! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
