On 8 November 2018 at 10:59, Li Zhijian <lizhij...@cn.fujitsu.com> wrote: > In order to support >= 2G initrd, we need to change len type from int to > uin32_t. > > Below is the flow sample to show how qemu copy initrd from qemu > side to VM when using optionroms bootlinux_dma.bin: > dma_memory_read(uint32_t len) > -> dma_memory_rw(uint32_t len) > -> dma_memory_rw_relaxed(uint32_t len) > -> address_space_rw(int len) # len overflow > -> address_space_read_full(int len) > > CC: Paolo Bonzini <pbonz...@redhat.com> > CC: Peter Crosthwaite <crosthwaite.pe...@gmail.com> > CC: Richard Henderson <r...@twiddle.net> > CC: Philip Li <philip...@intel.com> > Signed-off-by: Li Zhijian <lizhij...@cn.fujitsu.com>
If we change this, then "uint32_t" is not the right type. If we want to allow writes of large chunks of memory through this API then the right type for the length of a chunk of guest memory is "hwaddr". The other way to approach this would be to say that devices doing DMA mustn't try to do it in enormous chunks like this, but need to split it up. If we had a coherent story for how to avoid dma-engine device emulations from sitting in a loop forever doing guest-requested DMA this would probably tie in with that, as part of saying "don't do more than X amount of work at a time without yielding control back to QEMU". thanks -- PMM
