Am Thu, 18 May 2017 14:42:20 -0700
schrieb jonas <jo...@retotech.se>:
> > > Hi again,
> > >
> > > Let's assume that I want to modify
> > > jailhouse/inmates/demos/arm/gic-demo.c to also handle ivshmem
> > > interrupts generated by the hypervisor to the bare-metal cell when
> > > writing the virtual PCI driver config area using
> > > uio_ivshmem/uio_send in the root-cell.
> > >
> > > The first thing I would have to do is enable the IVSHMEM_IRQ in
> > > jailhouse/inmates/demos/arm/gic-demo.c:inmate_main() by calling
> > > gic_enable_irq(IVSHMEM_IRQ); in the same manner as
> > > gic_enable_irq(TIMER_IRQ);.
> > You would have to register a handler first, gic_setup() but yes.
> > > I would also have to check what irqn is passed in
> > > jailhouse/inmates/demos/arm/gic-demo.c:handle_IRQ(unsigned int
> > > irqn), in order to distinguish between TIMER_IRQ and IVSHMEM_IRQ,
> > > right?
> > I am not sure but it looks like gic_setup() might actually redirect
> > all interrupts to that one handler. Because you do not need to
> > specify the number. That check is there to not react to other
> > interrupts, there are probably no others.
> > > TIMER_IRQ is defined (to 27) in
> > > jailhouse/inmates/lib/arm/include/mach.h. Where does this value
> > > come from?
> > Probably from some ARM manual describing the interrupt controller
> > GIC, or maybe from the device tree, i do not know too much about
> > ARM. But it is basically a constant for your target.
> > > How do I know what value to set IVSHMEM_IRQ to?
> > Have a look at the linux inmate config for the bananapi. You will
> > have to get some pieces for your inmate config.
> > Get
> > .vpci_irq_base = 123,
> > and the irqchips section. Make sure you adjust the array size for
> > irqchips.
> > From the pin_bitmap you just need the second value
> > 0, 0, 0, 1 << (155-128),
> > And now your IVSHMEM_IRQ is 155. That should work, but i also cant
> > fully explain where the numbers come from.
> > Henning
> > > Still a bit confused - Jonas
> > >
> Thanks Henning,
> I tried the suggested additions to the bare-metal cell configuration
> and inmate, but no success yet. I use 'uio_send /dev/uio0 10 0 0' to
> fire 10 interrupts from the root-cell.
> Any suggestions on how to proceed?
You could instrument ivshmem_remote_interrupt and
arch_ivshmem_trigger_interrupt and other functions on the way with
I guess the interrupt is leaving the hypervisor but your inmate does
not receive it. You could integrate the timer-code from gic-demo into
your inmate to verify that the cell is able to receive interrupts at
And maybe the 155 is wrong after all but you could see that with the
instrumentation of the hypervisor.
> Verify that accesses to the virtual PCI device configuration area
> actually are made, intercepted by the hypervisor and interrupts
> generated to the bare-metal cell when running 'uio_send'?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.