On Wed, Jan 23, 2013 at 01:02:57PM +0100, Emmanuel Blot wrote: > I need to emulate a ARM-based SoC that handles a continuous > datastream, extracting and injection data with DMA tranfers from/to > the guest main memory. > > I've been using the cpu_physical_memory_* (read/write/map/unmap) > functions to perform data transfer, but I'd like to use several > dedicated native/host threads to emulate the datastream pipe, as many > CPU-intensive tasks (encryption, decryption, filtering) are involved > and to take advantage of multi-core host CPUS. > > What is the best approach to write this kind of code with the current > version of QEMU (1.4 dev)? > > Concurrent threads need to access guest main memory, and report > completion (I'm using qemu_bh_schedule to report completion). I do not > see other possible locations for race conditions for now. > > Is this possible ? I've not been able to figure out if this is the > right way to go, how to protect the cpu_physical_memory_* & > qemu_bh_schedule from race conditions. > > Or am I taking a dead-end path?
Today you cannot use cpu_physical_memory_*() from a thread without holding the QEMU global mutex. We need a thread-safe (and hopefully cheap) memory access API eventually but it doesn't exist yet. Have you tried taking the mutex temporarily just for map/unmap and then doing the copy or I/O outside the mutex? qemu_bh_schedule() should be thread-safe (but please double-check). Stefan
