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