qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu Unix-Signals


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] Qemu Unix-Signals
Date: Wed, 17 Apr 2013 19:07:39 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Apr 17, 2013 at 03:04:48PM +0200, Andreas Färber wrote:
> Hi,
> 
> Am 17.04.2013 11:21, schrieb Moese, Michael:
> >> I think your best bet is to ask GreenSocs if you need support for this 
> >> codebase.
> > 
> > I think you'd be right when you point me to GreenSocs, but.. they don't 
> > seem to support all this anymore.
> > 
> > 
> >> This is really ancient in QEMU terms, and how the internals work has 
> >> changed enormously since then.
> > 
> > Given I'd port their work over to a current QEMU source tree, would it be 
> > save then to use a signal, like SIGUSR2?
> > I cannot find any use of these signals in the (old) sources, but I want to 
> > be sure not to add unwanted side effects
> > when I just change the signal handler in my initialization code.
> > The differences seem to be only in some files of the sources, maybe I can 
> > port this stuff over to the current version, 
> > as this might be useful not only to me for my thesis right now but to some 
> > other developer for hardware-software-
> > co-simulation.
>

Hi,
 
> If you were to rebase onto the latest git version, you could as of
> yesterday use the qtest protocol interface outside of qtest to inject
> IRQs, IIUC. :-)

My understanding is that you can only monitor IRQ state over
qtest, not directly control it. It would be nice to add support for it
though.

I don't think signals are a good approach. You'd need to pass
some data along with the signal (low/high and irq nr/id) so it's
probably better to do it on top of some kind of data passing protocol.

Some years ago I hacked on a binary remote bus protocol (RBUS) allowing
remote devices to be attached to QEMU machines. I was using it at AXIS to
connect multiple QEMU instances for modeling heterogenous CPU arch SOCs
and as a test port (like QTest).
Later, Petalogix and Peter Crosthwaite (I think) used a modified version
of it to do co-simulation of QEMU with remote devices running on FPGAs.

I havent rebased it for years though and I also dont think rbus
was good enough. But I am interested to do something like that again.

I guess it can be viewed as a binary qtest protocol on steroids.

Best regards,
Edgar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]