Re: [Qemu-devel] need advice on PCI board emulation

[Paul Brook <paul@codesourcery.com>]

On Friday 08 December 2006 10:52, jerome Arbez-Gindre wrote:
> Hi,
>
> I'm working on a modem PCI board emulation inside Qemu.

Qemu already emulates a reasonably modern PCI system.

> My emulation is neerly functionnaly complete, but I have some doubt on
> my technical choices :
>  - to emulate dma transfers, I launch one thread for each dma channel.

Does this really provide any significant speedup? ie. does qemu spend 
significant amounts of time doing dma transfers?

>  - to emulate posponed starting behaviors (board self tests), I launch a
> thread with a sleep and then board status changes.

You should just use timers.

>  - to emulate demodulated incoming data, I launch one thread waiting
> with blocking reads on a UDP socket.

Again, why use threads?

> Because I had some toubles (segfaults in tb_reset_jump_recursive2
> (exec.c)), I have serilized my calls to pci_set_irq with the help of a
> new thread.
>
> So, my question is :
> 	Is it reasonable to use threads to emulate parallel behaviors ?

Maybe. With the possible exception of processing graphics, I wouldn't expect 
there to be very limited scope for parallelism in peripheral emulation. Most 
things are limited by the speed of the underlying device, or how fast the 
guest CPU can process the data.

You're liable to spend more time fighting for locks and waiting for cache 
flushes bouncing data between different CPUs than you gain from using 
multiple cores. On single cpu systems (which are still common in low-end 
machines) using threads is almost certainly going to slow things down.

If you look at the current code, you'll notice that most of the operations 
that can block for a long time waiting for external inputs (IDE/SCSI/USB) 
already operate asynchronously, and network is fairly asynchronous anyway.

Paul