I instrumented the code with several prints. When I start the bare-metal cell, I can see that an interrupt from CPU 3 is issued and handled by CPU 0:
Started cell "gic-demo-ivshmem" ivshmem_register_mmio() mmio->address = 8, mmio->is_write = 0, current cpu = 3 ivshmem_register_mmio() mmio->address = 0, mmio->is_write = 1, current cpu = 3 arch_ivshmem_update_intx(ive=0x0000ffffc02450a0), device->info->num_msix_vectors = 0, ctrl eg intx enable = 1 ivshmem_register_mmio() mmio->address = 12, mmio->is_write = 1, current cpu = 3 @@@@@ ivshmem_remote_interrupt() ive->remote: 0x0000ffffc0245000, current cpu = 3 arch_ivshmem_trigger_interrupt(ive:0x0000ffffc0245000), irq_id:136, current cpu = 3 irqchip_set_pending(), local_injection = 0, sender (current cpu) = 3 irqchip_set_pending() -> inside if(!cpu_data) irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:136), is_sgi(irq_id) = 0 irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, cpu_data->cpu_id = 0 arch_handle_phys_irq calling irqchip_set_pending(cpu_data=0x0000ffffc021d000, irqn=136), cpu_id = 0 irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 irqchip_set_pending() -> just return after irqchip.inject_irq, cpu_data->cpu_id = 0 irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 irqchip_set_pending() -> just return after irqchip.inject_irq, cpu_data->cpu_id = 0 When I run the program to generate an interrupt from Linux, I got the following output: /dev/mem opened. Memory mapped at address 0x7f988f2000. Writing 1 to 0x7f988f200c ivshmem_register_mmio() mmio->address = 12, mmio->is_write = 1, current cpu = 1 @@@@@ ivshmem_remote_interrupt() ive->remote: 0x0000ffffc02450a0, current cpu = 1 arch_ivshmem_trigger_interrupt(ive:0x0000ffffc02450a0), irq_id:136, current cpu = 1 irqchip_set_pending(), local_injection = 0, sender (current cpu) = 1 irqchip_set_pending() -> inside if(!cpu_data) irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:136), is_sgi(irq_id) = 0 irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, cpu_data->cpu_id = 0 arch_handle_phys_irq calling irqchip_set_pending(cpu_data=0x0000ffffc021d000, irqn=136), cpu_id = 0 irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 irqchip_set_pending() -> just return after irqchip.inject_irq, cpu_data->cpu_id = 0 irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:25), is_sgi(irq_id) = 0 irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, cpu_data->cpu_id = 0 irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 irqchip_set_pending() -> just return after irqchip.inject_irq, cpu_data->cpu_id = 0 Seems that the connection between Linux (root-cell) and the bare-metal one is not correct, but the other way around is fine. Why is that? > 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 /proc/interrupts: > > > > CPU0 CPU1 CPU2 > > 38: 38 0 0 GICv2 136 Edge uio_ivshmem, > > 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 > > (https://www.mail-archive.com/jailhouse-dev@googlegroups.com/msg02605.html), > > 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, > IVSHMEM_REG_DBELL access. > > > > > 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 > missing. > > Jan > > > > > Giovani > > > >> > >> 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. > >> > >> Jan > > > > -- > 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 "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.
