Den tisdag 16 maj 2017 kl. 16:54:35 UTC+2 skrev Henning Schild: > You do not need to know the number, the uio-driver knows it. And the > bare metal inmate does not need to know it since it is just writing to > a register to trigger it. > It looks like it is working. After loading the driver you should see a > new entry in /proc/interrupts. And when the inmate runs you should see > the counter going up.
Unfortunately not (just yet...). I've commented out the part where the bare-metal ivshmem-demo inmate writes to the IO-mapped ivshmem register of the virtual PCI device. The last thing I see in the inmate terminal window (after adding the printout prior to writing to the ivshmem register area) is: IVSHMEM: 00:00.0 sending IRQ (by writing to 0x7c00000c) In the terminal window of the Linux root-cell I see: FATAL: Invalid ivshmem register read, number 04 FATAL: forbidden access (exception class 0x24) pc=0xbf00b018 cpsr=0x600c0193 hsr=0x93800006 r0=0x0000007c r1=0xdd4f3600 r2=0x00010001 r3=0xdf948000 r4=0xc08d0000 r5=0xdd144290 r6=0xc0959325 r7=0x0000007c r8=0x0000007c r9=0xc08a3a40 r10=0x00000000 r11=0xc08d1e0c r12=0xc08d1e10 r13=0xc08d1e00 r14=0xc03d4dfc Parking CPU 0 (Cell: "Banana-Pi") If i comment out the line in the bare-metal inmate where the register is written (in ivshmem_demo.c:send_irq(), mmio_write32(d->registers + 3, 1);), all seems to be well and I am able to verify that the shared memory has been updated by the bare-metal inmate from within the root cell. I've also been able to verify that the contents of the shared memory area is picked up by the bare-metal inmate. No interrupts from the inmate to the root cell though (of course). Since I'm able to access the virtual PCI device register area using mmio_read32() from the inmate, it looks like the area has not been mapped for write access (by Jailhouse)? Am I missing some PCI device configuration entry? I tried to find where the FATAL:-printouts come from and found traces to jailhouse/hypervisor/ivshmem.c:ivshmem_register_mmio() and jailhouse/hypervisor/arch/arm/traps.c:arch_handle_trap(). I don't know what to do with this information at the moment. Is it possible to dump some call-stack from the hypervisor when fatal errors occur? > Getting an IRQ sent to the inmate will be more tricky, you will need to > program the GIC where the x86 code does "int_set_handler". The gic-demo > should give a clue. Yep, I've started looking at this example. Thanks for verifying that this is the way forward. > > > Does the uio_ivshmem driver take care of generating interrupts from > > the root-cell to the bare metal cell, or do I need to modify this as > > well? > > The uio-driver does not actually do anything. It just makes the > ressources of the "hardware" visible to userland. I suggest you have a > look at the jailhouse specific README. > https://github.com/henning-schild/ivshmem-guest-code/blob/jailhouse/README.jailhouse > If you did not come across this file yet you might be on the wrong > branch of ivshmem-guest-code. I've seen it. I'm on the jailhouse branch of ivshmem-guest-code. Thanks - 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.
