[Qemu-devel] need advice on PCI board emulation

[Qemu-devel] need advice on PCI board emulation

[jerome Arbez-Gindre]

Hi,

I'm working on a modem PCI board emulation inside Qemu. 
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.
 - to emulate posponed starting behaviors (board self tests), I launch a
thread with a sleep and then board status changes.
 - to emulate demodulated incoming data, I launch one thread waiting
with blocking reads on a UDP socket.

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 ?

if Yes :
	How could I make my calls to Qemu APIs more robust ?

If No :
	What is the *Good* way ?

Thanks

	Jérôme

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

[Paul Brook]

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

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

[jerome Arbez-Gindre]

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

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

[Paul Brook]

> I'm working on a modem PCI board emulation inside Qemu.

I misread "modem PCI board" as "modern PCI board" in your original post. The 
correct response is much shorter:

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

You should use the existing serial devices.

> So, my question is :
> 	Is it reasonable to use threads to emulate parallel behaviors ?

No. You should copy how the existing devices (eg. serial ports) work.

You don't need parallel operation. Modems are low-bandwith devices, so you're 
not going to get any performance benefit from using multiple threads.

Paul

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

[jerome Arbez-Gindre]

On Fri, 2006-12-08 at 15:22 +0000, Paul Brook wrote:
> > I'm working on a modem PCI board emulation inside Qemu.
> 
> I misread "modem PCI board" as "modern PCI board" in your original post. The 
> correct response is much shorter:

I've replied to your former message before reading this one, sorry !

> 
> >  - to emulate demodulated incoming data, I launch one thread waiting
> > with blocking reads on a UDP socket.
> 
> You should use the existing serial devices.

I need demodulated data in my board emulation.
The aim of my project is to emulate a PCI board which does not exist at
this time, to help working on the driver.
I hope it will just work when i'll receive the first real board
prototype.

> 
> > So, my question is :
> > 	Is it reasonable to use threads to emulate parallel behaviors ?
> 
> No. You should copy how the existing devices (eg. serial ports) work.

As said, in my previsous message, I'll go deeper in the read of Qemu
sources.

> 
> You don't need parallel operation. Modems are low-bandwith devices, so you're 
> not going to get any performance benefit from using multiple threads.

The modem should handle 30 Mb/s.
I'm looking for realistic behaviour, performances is not a priority

Jérôme