Am Wed, 17 May 2017 02:13:24 -0700
schrieb jonas <[email protected]>:

> 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")

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.

> 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

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

Reply via email to