Hi Jan,
On 22-Jul-19 7:11 PM, von Wiarda, Jan wrote:
> Hi Mark,
>
> I'm not touching bit 13 or 14 in HCR_EL2, they're both 0. HCR_EL2 is the same
> for 64 bit and 32 bit inmates when the crash happens, except for HCR_RW_BIT,
> obviously. HCR_EL2 value is 0x28001B at crash time.
>
It's quite an interesting crash that you have there; I wouldn't expect this to
happen.
The idea with trapping WFI/WFE is to be able to suspend a VM that is just
waiting for something to happen. Since Jailhouse is a partitioning hypervisor,
you shouldn't need to trap it, nor should its use normally influence the other
cores. Yet something is amiss here.
Is the root cell cpu (CPU 0) specifically crashing with an unexpected
synchronous exit to Jailhouse? What is the output?
I don't remember what event 0x28001B maps to, I would check the ARM ARM first
to figure out what the unexpected event in CPU 0 was, for a clue to motivate
further investigation.
Additionally, this WFI code instructs the compiler that memory contents may
change, so ordering of generated instructions, inserted barriers etc, are
influenced. This is a far shot, but maybe the code generated around the WFI is
the culprit? Maybe not, but I would try to rule it out:
(a) First I'd try replacing the WFI with a nop, to observe the behavior without
the WFI but without changing compiler behavior and maintaining any compiler
barriers.
(b) I would also try replacing it with an infinite loop ("b .") to get the
inmate to wait forever at this position, and see what happens.
Happy debugging :)
Best regards,
Tony
--
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/5518ab89-15c7-c1c2-c56e-f840cc296cec%40huawei.com.
