[Qemu-devel] Qemu Unix-Signals

[Qemu-devel] Qemu Unix-Signals

[Moese, Michael]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Hello QEMU developers,
After doing some search in the list archives and the web as well as greping the (hower quite old - version 0.10.5 ) sources,
I think I need to consult you for some hints. I know my version is quite outdated, but I need this one for it's
SystemC-integration done by GreenSocs.

Now, to my question: does QEMU use all the available signals, or are there just signal handlers installed for each signal?
Is there any unused signal I could use?


Below some explanation of what I try to do:

I think when I need to deliver IRQ's from another unix process to QEMU, there is no better solution than sending a signal,
but correct me if I'm wrong. I already have a working, simulated PCI-Device (written in SystemC)  which can send interrupts
to my virtual machine - both are running inside the same unix process, and now I want to add another
SystemC-simulation in another process doing the real hardware simulation.

Thank you for reading my question, maybe you can help me or point me to where to find what I need?

Michael


[-- Attachment #2: Type: text/html, Size: 3875 bytes --]

Re: [Qemu-devel] Qemu Unix-Signals

[Peter Maydell]

On 17 April 2013 09:02, Moese, Michael <michael.moese@men.de> wrote:
> Hello QEMU developers,
>
> After doing some search in the list archives and the web as well as greping
> the (hower quite old - version 0.10.5 ) sources,

This is really ancient in QEMU terms, and how the internals work
has changed enormously since then.

> I think I need to consult you for some hints. I know my version is quite
> outdated, but I need this one for it’s SystemC-integration done by GreenSocs.

I think your best bet is to ask GreenSocs if you need support for
this codebase.

thanks
-- PMM

Re: [Qemu-devel] Qemu Unix-Signals

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

Thank you,
Michael

Re: [Qemu-devel] Qemu Unix-Signals

[Andreas Färber]

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.

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

Do note that either SIGUSR1 or SIGUSR2 is in use for timers or something
(and our Wiki page on debugging listed the wrong one last time I ran
into it ;)).

Regards,
Andreas

P.S. x.y.5 would be a development version, so there's no telling what
exactly it did.

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Qemu Unix-Signals

[Edgar E. Iglesias]

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