Hi Angelo,
please avoid top-posting on MLs.
On 17.03.20 10:59, Angelo Ruocco wrote:
Hi all,
This is some really interesting work, and we are planning to do some
tests here at the HiPeRT lab in Modena on some other GICv3 boards by
NXP.
I thought there was already a hypervisor in your lab that does not
"depend on Linux to boot and manage its VM"? ;)
Regarding this, what is the long-term plan? Are you interested in a
collaboration for this to have a broader support, with more features
and be nearer to be production-ready?
This approach clearly has a future in Jailhouse upstream once details
such as the code duplication with the inmate library and the propagation
(or lock-down) of root-cell functionality are clarified. In fact, I
would like to see this pattern also on x86 and upcoming RISC-V.
Jan
Thanks,
Angelo
2020-03-05 13:39 GMT+01:00, Peng Fan <[email protected]>:
[email protected]
Cc: Alice Guo <[email protected]>
Subject: Re: [PATCH 0/2] boot jailhouse before root cell linux
On 05/03/20 3:09 PM, [email protected] wrote:
From: Peng Fan <[email protected]>
This patchset tested on i.MX8MN arm64 with quad A53 cores
Patch 1 is to align jailhouse_system. Since the loader not have MMU
enabled, unaligned access will cause abort.
Patch 2 is not that well orgnized. It does GICv3 initialization, SMP
boot up. Then kick inmate cell and root cell.
Some code are hardcoding for now.
The boot log as below, you could see root linux and gic demo both
running:
root cell not able to manage inmate cell for now. But I think it could
be supported. intercell communication not aded currently.
From test log, linux root cell boot will cause large latency for
gic-demo jitter.
It maybe good to use cache color on ARMv8, but still have issues for
root cell DMA without SMMU.
[..snip..]
Nice to see this being supported...!!!
Timer fired, jitter: 749 ns, min: 749 ns, max: 7999 ns
[ 0.127643] Detected VIPT I-cache on CPU1
[ 0.127671] GICv3: CPU1: found redistributor 1 region
0:0x00000000388a0000
[ 0.127700] CPU1: Booted secondary processor 0x0000000001
[0x410fd034]
[ 0.159684] Detected VIPT I-cache on CPU2
[ 0.159700] GICv3: CPU2: found redistributor 2 region
0:0x00000000388c0000
[ 0.159717] CPU2: Booted secondary processor 0x0000000002
[0x410fd034]
[ 0.191721] psci: failed to boot CPU3 (-1)
[ 0.227974] CPU3: failed to boot: -1
[ 0.231609] smp: Brought up 1 node, 3 CPUs
Did not look closer but couple of questions:
- I guess the above CPU is given to inmate cell.
Yes.
We should be able to handle
this error gracefully rather than failure. Wondering how other
hypervisors
handle this.
It is because dts file has 4 cpus, so it will surely fail.
To XEN, xen will take over dtb, and runtime create a new dtb for dom0.
- What level of features supported when compared with type 2?
Just a few in mind
Fast inmate boot.
Easy to support aarch32 root cell with aarch64 jailhouse
Decouple Linux as root cell, so not a must to take Linux as root cell.
Cache color would be possible for root cell
Regards,
Peng.
Thanks and regards,
Lokesh
--
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/AM0PR04MB448105AD6E53770A3BED0E5B88E20%40AM0PR04MB4481.eurprd04.prod.outlook.com.
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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/81f9a1c9-a4c2-ff0c-f387-90c959da9313%40siemens.com.
