Am Wed, 17 May 2017 04:54:07 -0700 schrieb jonas <[email protected]>:
> > > > > 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") > > > > > > Seems like the Intx path was never really tested with the uio > > > driver. I think the problem is caused be the interrupt handler > > > ivshmem_handler in uio_ivshmem.c > > > It is trying to read the IntrStatus register which jailhouse does > > > not implement. Just make the function a pure "return > > > IRQ_HANDLED;" and you should get further. Actually you error > > > indicates that the interrupt was received because Linux ran the > > > basic uio handler. > > > > Yes, that does do the trick! > Before starting the ivshmem-demo bare-metal inmate the interrupt > count for ivshmem as reported by /proc/interrupts is zero. After > having started the inmate it is one (I just write once to the LSTATE > register from the inmate). > > > I do not remember why the Status register is not implemented by > > jailhouse, maybe Jan does. Or i would have to read up in the archive > > and see whether it was ever part of the patchsets that introduced > > ivshmem. > > > > Hehe - That was my next question... > > > I just pushed a patch to the jailhouse-next branch, it compiles but > > i did not test it .... You could give it a try. > > > > OK, I'm currently on v0.6. Do I want to switch to jailhouse-next in a > hurry, or am I good for now on v0.6? Eventually I will move on to > newer branches/tags, of course, and upstream my findings. I was talking about ivshmem-guest-code, not jailhouse. Henning > > Henning > > > > > > 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? > > > > > > The function ivshmem_register_mmio was the right place to look. > > > Now if you look at the error you see that linux tried to read > > > register 4. And that register is not handled by jailhouse, have a > > > look at IVSHMEM_REG_* in ivshmem.c. > > > > > > > > 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 > > > > > Thanks a bunch for the swift response - 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.
