Hi Jan, On Fri, May 20, 2022 at 7:08 AM Jan Kiszka <[email protected]> wrote: > > On 19.05.22 15:23, Lad, Prabhakar wrote: > > Hi Jan, > > > > On Thu, May 19, 2022 at 12:39 PM Jan Kiszka <[email protected]> wrote: > >> > >> On 19.05.22 11:44, Lad, Prabhakar wrote: > >>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka <[email protected]> wrote: > >>>> Forgot: that cannot work. The call of arm_dcaches_flush will overwrite > >>>> lr, thus the second ret will only return to where the first ret jumped > >>>> to - endless loop. You would have to restore lr (x30) from x17 in > >>>> arch_entry first: > >>>> > >>>> mov x30, x17 > >>>> ret > >>>> > >>> That did the trick thanks! > >>> > >>> diff --git a/hypervisor/arch/arm64/entry.S b/hypervisor/arch/arm64/entry.S > >>> index a9cabf7f..7b340bd1 100644 > >>> --- a/hypervisor/arch/arm64/entry.S > >>> +++ b/hypervisor/arch/arm64/entry.S > >>> @@ -109,6 +109,8 @@ arch_entry: > >>> mov x0, #LINUX_HVC_SET_VECTORS_LEGACY > >>> 1: > >>> hvc #0 > >>> + mov x30, x17 > >>> + ret > >>> > >>> hvc #0 /* bootstrap vectors enter EL2 at el2_entry */ > >>> b . /* we don't expect to return here */ > >>> > >>> > >>> With the above diff I do get the below: > >>> > >>> [ 42.980805] jailhouse: loading out-of-tree module taints kernel. > >>> Reading configuration set: > >>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) > >>> Overlapping memory regions inside cell: None > >>> Overlapping memory regions with hypervisor: None > >>> Missing resource interceptions for architecture arm64: None > >>> [ 46.582588] obcode @arm_dcaches_flush: d53b0024 > >>> [ 46.582616] obcode @arm_dcaches_flush: d53b0024 > >>> [ 46.611311] The Jailhouse is opening. > >>> > >>> So it looks like something to do with the debug console. This has to > >>> be poked in the dark or any easy way to debug? > >> > >> Well, we do not yet know what goes wrong. We do know that we can call > >> into the hyp take-over stub and register Jailhouse with it. We do not > >> know if we will then end up in Jailhouse in hyp mode and just lack > >> console output or if we crash on entry already. > >> > > Right agreed. > > > >> To move the uart console out of the picture: Did you already check if > >> the driver you select in the Jailhouse config is actually one that > >> should support the UART on your board? Next is to double check if poking > > The UART on this platform is almost identical to > > JAILHOUSE_CON_TYPE_SCIFA type, but with some differences which I have > > patched to work on this platform. > > > >> registers in the way the Jailhouse driver will do at the addresses you > >> configured will work: Pull the code into the kernel module or even into > >> a userspace application with /dev/mem raw register access and try out if > >> that works in a "safe" environment (without hypervisor mode). > >> > > Sure will give that a shot, any pointers on doing this from userspace? > > > > Something like this may help if you do that the first time: > https://bakhi.github.io/devmem/ > Thanks for the pointer. I have tried reading/writing from the hypervisor location and that goes all OK. To avoid any issue related to debug UART is there any way I could test this prior to enabling?
Cheers, Prabhakar -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/CA%2BV-a8vshtRo3Kot2xCVV%3DL%2BkySoP1XkOrc3U8tWXxLeCCb4Ow%40mail.gmail.com.
