Am Fri, 19 May 2017 07:15:17 -0700
schrieb jonas <jo...@retotech.se>:
> Den fredag 19 maj 2017 kl. 13:13:15 UTC+2 skrev Henning Schild:
> > Am Fri, 19 May 2017 03:22:05 -0700
> > schrieb jonas <jo...@retotech.se>:
> >
> > > Den fredag 19 maj 2017 kl. 11:22:06 UTC+2 skrev Henning Schild:
> > > > 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 printfs
> > > > 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 all.
> > > > And maybe the 155 is wrong after all but you could see that
> > > > with the instrumentation of the hypervisor.
> > > >
> > > > Henning
> > > >
> > > > > 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'?
> > > > >
> > > > > /Jonas
> > > > >
> > >
> > > Good suggestion! Actually, that is exactly what I did this
> > > morning.
> > >
> > > In
> > > hypervisor/arch/arm-common/ivshmem.c:arch_ivshmem_trigger_interrupt(),
> > > I added: ``` printk("%s(ive:%p), irq_id:%d\n", __func__, ive,
> > > irq_id); ```
> > >
> > > When running `uio_send /dev/uio0 10 0 0` I get:
> > > ```
> > > [UIO] ping #0
> > >
> > > [UIO] ping #1arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #2arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #3arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #4arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #5arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #6arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #7arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #8arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] ping #9arch_ivshmem_trigger_interrupt(ive:0xf0047090),
> > > irq_id:0
> > >
> > > [UIO] Exiting...
> > > ```
> > >
> > > Hence, since irq_id is 0, no interrupt is set pending in the
> > > irqchip...
> >
> > If you look at where the irq_id comes from you will find
> > (ive->intx_ctrl_reg & IVSHMEM_INTX_ENABLE).
> >
> > Have a look what uio_ivshmem.c is doing in line 207, that is
> > missing in your inmate.
> >
>
> Yay! It works!
Would be nice if you could try and wrap up your changes into a patch
and send that here for reference.
If you would like to try and get your changes merged they would have to
be generic. So no hardcoded interrupt numbers, pci bus locations etc.
Have a look at inmates/lib/cmdline.c to pass such values in as
arguments for your target. That mechanism is currently only used for
debug output and is also described in Documentation/debug-output.md
Henning
> > > I also added a printout in `hypervisor/arch/arm-common/irqchip.c`:
> > > ``` if ((irq_id != 30) && (irq_id != 33)) {
> > > printk("%s(cpu_data:%p, irq_id:%d)\n", __func__,
> > > cpu_data, irq_id); }
> > > ```
> > > which shows a lot of interrupts being handled (I had to filter
> > > out 30 (PPI 14) and 33 (UART 0) in order not to drown in
> > > printouts at startup).
> > >
> > > I can then see printouts for IRQ 2, (SGI 2), 4 (SGI 4), 64 (SD/MMC
> > > 0), 140 (IVSHMEM_IRQ for root-cell???, 108+32, as my root-cell
> > > config contains:`config.cell.vpci_irq_base = 108`?), and
> > > eventually when reaching steady state, only 117 (GMAC).
> > >
> > > I'm guessing that I should have seen corresponding printouts for
> > > IRQ 155 (123+32, as my bare-metal cell
> > > contains:`config.cell.vpci_irq_base = 123`) if all would have
> > > been OK?
> > >
> > > I've used the A20 User Manual Revision 1.0 Feb. 18, 2013 from
> > > Allwinner as reference for interrupt source numbers mentioned
> > > above.
> > >
> > > According to this, it seems like 108 coincides with GPU-RSV0.
> >
> > I guess the vpci_irq_base for a SoC would be the last irq the thing
> > uses plus some alignment. Jailhouse is using 140 not 108.
>
> The last interrupt source number used by A20 is 122 (IIS 2), so the
> first unused is 123.
>
> >
> > Henning
> >
> > > /Jonas
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
