qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] QEMU & multithreaded device emulation


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] QEMU & multithreaded device emulation
Date: Wed, 23 Jan 2013 14:08:21 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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