DOR : Example for injecting the interrupt to the guest

Hello Dor,

Can you please point to an example that injects interrupts via userspace ?

I am running QNX as Guest and Linux as Host. One of my QNX application (Guest application), expects an interrupt from the Hardware.

Now as I understand this, I need to write a driver on the host side to get the interrupt and somehow inject the interrupt to guest OS. But I am not sure how to signal the KVM about the arrival of interrupt, without breaking anything.

Ghaskins, suggested your name in kvm-irc. I have pasted relevant part of it for your reference.

Your early response will be highly appreciated,

Thanking you

Aji

10:36 < aji003> the virtual driver is a part of kvm...and so it runs in the host
10:36 < ghaskins> ok, so yes you are correct
10:36 < ghaskins> the host side would know the real vector of the physical device and would be registered in the host IDT 10:36 < aji003> By virtual driver I mean, the driver I have developed so that the guest app can interact with the physical hardware 10:36 < ghaskins> it would then probably do something like proxy the interrupts into the guest
10:37 < ghaskins> ok, i understand you now
10:37 < ghaskins> so your proxy/virtual driver would get the real interrupt...you then would want to inject it into the guest as a virtual interrupt 10:37 < aji003> yes thatz what I wanted to do..sorry if i confused you
10:38 < ghaskins> no problem..its clear now
10:38 < ghaskins> so I assume you already know how to write your virtual driver and register it with linux with the write vector, etc 10:38 < ghaskins> ?
10:38 < ghaskins> and now you just want to know how to inject the interrupt to the guest
10:38 < aji003> I did it for I/O and memory mapping, but I am not sure about how to do for interrupt
10:41 < ghaskins> so are we on the same page: your proxy will handle the real vector?
10:42 < aji003> KVM has a virtualised 8259 driver
10:43 < ghaskins> yeah, but that code is also in flux right now too
10:43 < ghaskins> as of right now, the interrupt infrastructure is all in userspace/QEMU
10:43 < ghaskins> its in the process of being moved down into the kernel
10:44 < ghaskins> at that point it will be much easier to inject interrupts from the kernel, which it sounds like you might need to do 10:44 < aji003> ok
10:44 < aji003> so with qemu, itz not possible ?
10:44 < ghaskins> but as a high level overview, there are emulated 8259s and APICs
10:45 < ghaskins> well, it should be possible...its just more difficult
10:45 < aji003> ok..
10:45 < ghaskins> I think Dor has written a driver that utilizes the userspace interrupt stuff as you would need to
< ghaskins> I think Dor has written a driver that utilizes the userspace interrupt stuff as you would need to
10:45 < aji003> Dor ?
10:46 < aji003> I am quite new to linux and KVM
10:46 < ghaskins> He's one of the Qumranet guys...if he is not here on IRC just hit the list
10:46 < ghaskins> [email protected]
10:46 < ghaskins> he can probably point you to an example of his that injects interrupts via userspace
10:46 < aji003> ok
10:47 < ghaskins> and it will all get a little simplified in a few weeks when the in-kernel stuff merges
10:47 < aji003> Thanks ghaskins

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

userspace

am

of

Actually we're in the middle of developing pci pass through support for enabling
physical device pass through for guests. It's work in progress but eventually we'll
post the code to the list.
In our case, maybe yours too, we need to first receive the irq in the host, mask it
and inject it to the guest. Only after the guest acks the irq it should be cleared in the host.
That's the general scheme although there are some hacks in order to pass possible deadlocks that
might be caused by shared irq device.

Anyway, the relativly easy part is to inject the irq to the guest. As Gregory soon the pic/apic/ioapic will move into the kernel and it will be easier.
Until then you can send a signal from the kernel to qemu's main thread (get_pid also recommended for safety).
The signal handler in qemu only sets a flag and schedules a qemu_bh (like the kernel's bottom half).
The bh handler call the pci_set_irq of the right device. You can also use the apic/ioapic directly too.

What's the nature of the project? We can send you some early code samples.
--Dor

so

virtual

virtual

kernel

8259s

userspace

weeks

-

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Cool. Are you relying on an isolation-capable IOMMU or using the Neocleus approach?

Cheers,
Muli

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Actually we'll do both.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Doubly cool. Looking forward to more information.

Cheers,
Muli

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/