Den onsdag 17 maj 2017 kl. 11:13:24 UTC+2 skrev jonas: > 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?
Hmm... Does the access originate from the root-cell, since the root cell is being parked, not the (non-root) cell in which the bare-metal inmate is running? Can I turn on some more debugging info in the hypervisor? /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.
