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 <[email protected]>:
>
> > 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 <[email protected]>:
> > >
> > > > >
> > > > > > 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!
> > 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
