> > > > 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. > 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.
