[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] need advice on PCI board emulation
From: |
jerome Arbez-Gindre |
Subject: |
Re: [Qemu-devel] need advice on PCI board emulation |
Date: |
Fri, 08 Dec 2006 17:57:38 +0100 |
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