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

[jerome Arbez-Gindre <jerome.arbez-gindre@laposte.net>]

On Fri, 2006-12-08 at 15:07 +0000, Paul Brook wrote:
> 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.
> 

I'm emulating a MODEM (not modern;-)) pci board ... and for this, i'm
using the Qemu API.

> > 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?

My aim is to be as near as possible of the real system behavior.
In fact I'm speeding down the dma transfers, and I wan let Qemu (and my
driver) working during this time.

> 
> >  - 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.

Why not, but it does not resolve mutual exclusion problems.

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

To wait incoming data.

> 
> > 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.

My Qemu is running on a multi-processor machine.

> 
> 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.

I've looked in the current code. But I don't understand how asynchronous
mechanisms are taking the hand back.
Perhaps I should look deeper ;-)

> 
> Paul

Jérôme