On 29.05.22 12:53, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Sun, May 29, 2022 at 9:35 AM Jan Kiszka <[email protected]> wrote:
>>
>> On 28.05.22 21:13, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Sat, May 28, 2022 at 3:41 PM Jan Kiszka <[email protected]> wrote:
>>>>
>>>> On 28.05.22 15:22, Lad, Prabhakar wrote:
>>>>> On Fri, May 27, 2022 at 6:07 AM Jan Kiszka <[email protected]> wrote:
>>>>>>
>>>>>> If that should be the case, you could use the JTAG to "trace" how far
>>>>>> you get: Add an infinite loop at some point the setup should get along,
>>>>>> and then check with the debugger if PC points to that address and if EL2
>>>>>> is active. With that, you could also check if the UART print-out is
>>>>>> executed.
>>>>>>
>>>>> After tracing back I see it's looping infinitely somewhere in the
>>>>> hypervisor.o file, below is the code where it repeatedly loops.
>>>>>
>>>>> ffffc0209550: b9400680 ldr w0, [x20, #4]
>>>>> ffffc0209554: b9403481 ldr w1, [x4, #52]
>>>>> ffffc0209558: 6b00003f cmp w1, w0
>>>>> ffffc020955c: 540013a8 b.hi ffffc02097d0 <entry+0x2d8>
>>>>> .....
>>>>> ffffc02097d0: 17ffff60 b ffffc0209550 <entry+0x58>
>>>>>
>>>>> I haven't managed to find where exactly in the C file this is
>>>>> happening yet. Any thoughts on what could be happening?
>>>>>
>>>>
>>>> That's very likely
>>>>
>>>> while (entered_cpus < hypervisor_header.online_cpus)
>>>> cpu_relax();
>>>>
>>> Thanks for the pointer really appreciated.
>>>
>>>> Did you configure more CPUs than there are in the system?
>>>>
>>> No I haven't, I've set it up as cpus = 0x3f for 6 CPUs (2xa57 +
>>> 4xa53). I don't know what was happening there when I removed the
>>> infinite loop (which I used for break point) from entry.S that went
>>> OK. There was also an issue with the debug uart driver which I've
>>> fixed and able to get the prints now.
>>>
>>> So now moving forward I am seeing "Unhandled data read"!
>>>
>>> Looking at the address for Unhandled data read one belongs to GIC
>>> (0xf102f00c) and the other one belongs to the debug uart (0xe6e88008).
>>
>> Regarding GICC access: Try setting gicc_base to 0xf102f000 in the root
>> cell config.
>>
> Setting gicc_base to 0xf102f000 has solved the issue, I no longer get
> unhandled data reads now.
>
>> Regarding the UART: Do you pass that address through to the root cell as
>> well? It's generally fine to allow both hypervisor and one cell to
>> access the UART in parallel. Otherwise, disable UART usage by the root
>> cell prior to enabling Jailhouse.
>>
> No, I don't pass the UART address to the root cell as part of
> mem_regions. I just have it as part of the header config as below:
>
> .debug_console = {
> .address = 0xe6e88000,
> .size = 0x40,
> .type = JAILHOUSE_CON_TYPE_SCIFA,
> .flags = JAILHOUSE_CON_ACCESS_MMIO |
> JAILHOUSE_CON_REGDIST_4,
> },
>
> By disabling the UART usage by the root cell did you mean to use
> JAILHOUSE_CON_TYPE_NONE? I tried adding JAILHOUSE_CON_TYPE_NONE but I
No, I meant
- stop using the UART as kernel console
- stop running a getty on the UART (the latter happens automatically
with systemd when doing the former)
> don't get anything on the console after enabling the root cell. I even
> tried removing the entire debug_console{} from the root cell config
> but still I don't see any output on console.
>
> If I update the size to 0x1000 as below and also include it as part of
> mem_regions, I get to a state where I see the message "The Jailhouse
> is opening" but the console seems to be frozen.
Sorry, I missed one bit in the gic configuration pattern on some arm64
targets (scan configs/arm64): you also need to set gicv_base to
0xf106f000, then it will work (crossing fingers...).
Jan
--
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/69a0ae1d-1ee9-e99b-f190-d534ce86c227%40web.de.
