On 2018-04-16 20:35, Giovani Gracioli wrote:
> I added .vpci_irq_base = 136-32 to the bare-metal cell config (.cell) and now
> I can see the interrupts generated by uio_send through the output of cat
> CPU0 CPU1 CPU2
> 38: 38 0 0 GICv2 136 Edge uio_ivshmem,
> When uio_send writes, the interrupt handler of the uio driver is called twice
> per write (why??).
Well, Linux says that the line is shared by two uio devices, see above.
So both instances will be called on each arriving interrupt.
> .vpci_irq_base = 136-32 has the same value as defined in the root-cell.
> I added some prints to the
> hypervisor/arch/arm-common/ivshmem.c:arch_ivshmem_trigger_interrupt and
> hypervisor/arch/arm-common/irqchip.c as described in another thread
> but I can't see any output.
> So, something is still not well configured.
You can start such trace in hypervisor/ivshmem.c, ivshmem_register_mmio,
> The bare-metal inmate outputs the following when it starts:
> IVSHMEM: Found 1af4:1110 at 00:00.0
> IVSHMEM ERROR: device is not MSI-X capable
> IVSHMEM: shmem is at 0x0000000800400000, shmemsz is 0x0000000000100000
> IVSHMEM: bar0 is at 0x00000000fc100000
> IVSHMEM: mapped shmem and bars, got position 0x0000000000000001 - bdf = 0
> IVSHMEM: memcpy(0x0000000800400000, Hello from bare-metal ivshmem-demo
> inmate!!! , 64)
> IVSHMEM: 0x0000000800400000:Hello from bare-metal ivshmem-demo inmate!!!
> IVSHMEM: Enabled IRQ:0x88
> IVSHMEM: Enabling IVSHMEM_IRQs registers = 0x00000000fc100000
> IVSHMEM: Done setting up...
> IVSHMEM: Hello from bare-metal ivshmem-demo inmate!!!
> IVSHMEM: sending interrupt.
> IVSHMEM: sending IRQ - addr = 0x00000000fc10000c
> IVSHMEM: waiting for interrupt.
> I'm not sure about the IVSHMEM_IRQ number, that's why I inserted the prints.
The IRQ number is basically a free but GIC-wise supported SPI.
> Is there any other parameter that must be add to the bare-metal cell to allow
> it to handle ivshmem interrupts?
Did you cell enable INTx delivery? See the check in
arch_ivshmem_update_intx, and update the INTX_CTRL register if that is
>> Both values aren't evaluated by the current Jailhouse implementation
>> (see hypervisor/ivshmem.c, ivshmem_register_mmio, IVSHMEM_REG_DBELL
>> handling). There is only one vector per device (currently), and that is
>> send to the SPI configured in the peer cell's config.
>> Maybe there is a mismatch in what is configured and what the device tree
>> of that cell tells the Linux guest.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
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.