From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gsj2o-000598-Q8 for qemu-devel@nongnu.org; Fri, 08 Dec 2006 11:57:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gsj2n-00058s-Rl for qemu-devel@nongnu.org; Fri, 08 Dec 2006 11:57:54 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gsj2n-00058p-OA for qemu-devel@nongnu.org; Fri, 08 Dec 2006 11:57:53 -0500 Received: from [81.255.54.11] (helo=mx.laposte.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gsj2j-0005oY-9H for qemu-devel@nongnu.org; Fri, 08 Dec 2006 11:57:53 -0500 Received: from smtp.laposte.net (10.150.9.41) by mx.laposte.net (7.2.060.1) id 4553465F0172BCA4 for qemu-devel@nongnu.org; Fri, 8 Dec 2006 17:57:47 +0100 Received: from smtpin.laposte.net (10.150.9.72) by smtp.laposte.net (7.3.105.2) id 456F2BB000A8963F for qemu-devel@nongnu.org; Fri, 8 Dec 2006 17:57:40 +0100 Received: from bibi (217.128.241.130) by smtpin.laposte.net (7.2.060.1) (authenticated as jerome.arbez-gindre) id 45747F9A00022181 for qemu-devel@nongnu.org; Fri, 8 Dec 2006 17:56:31 +0100 Subject: Re: [Qemu-devel] need advice on PCI board emulation From: jerome Arbez-Gindre In-Reply-To: <200612081507.40975.paul@codesourcery.com> References: <1165575170.22384.16.camel@bibi> <200612081507.40975.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 08 Dec 2006 17:57:38 +0100 Message-Id: <1165597058.9321.13.camel@bibi> Mime-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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. >=20 > Qemu already emulates a reasonably modern PCI system. >=20 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 o= n > > my technical choices : > > - to emulate dma transfers, I launch one thread for each dma channel= =2E >=20 > Does this really provide any significant speedup? ie. does qemu spend=20 > 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. >=20 > > - to emulate posponed starting behaviors (board self tests), I launc= h a > > thread with a sleep and then board status changes. >=20 > You should just use timers. Why not, but it does not resolve mutual exclusion problems. >=20 > > - to emulate demodulated incoming data, I launch one thread waiting > > with blocking reads on a UDP socket. >=20 > Again, why use threads? To wait incoming data. >=20 > > 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 ? >=20 > Maybe. With the possible exception of processing graphics, I wouldn't e= xpect=20 > there to be very limited scope for parallelism in peripheral emulation.= Most=20 > things are limited by the speed of the underlying device, or how fast t= he=20 > guest CPU can process the data. >=20 > You're liable to spend more time fighting for locks and waiting for cac= he=20 > flushes bouncing data between different CPUs than you gain from using=20 > multiple cores. On single cpu systems (which are still common in low-en= d=20 > machines) using threads is almost certainly going to slow things down. My Qemu is running on a multi-processor machine. >=20 > If you look at the current code, you'll notice that most of the operati= ons=20 > that can block for a long time waiting for external inputs (IDE/SCSI/US= B)=20 > already operate asynchronously, and network is fairly asynchronous anyw= ay. 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 ;-) >=20 > Paul J=E9r=F4me