Hi,
I have a question about hafnium executing PSCI_CPU_ON.
So what I observe is,
if I define single SP with 2 Physical CPUs & 2 VCPUS defined in SPMC manifest for hypervisor and secure partition, respectively.
And when I do have > 2 cpus running in non-secure world, precisely at the moment when Linux brings up 3rd CPU with PSCI_CPU_ON, EL3 PSCI calls will be forwarded to hafnium running in secure EL2.
And this is where it hits.
And since hafnium doesn't find 3rd CPU defined in manifest it will hit "Dead stop here if no more CPU. */
.global cpu_entry
cpu_entry:
#if SECURE_WORLD == 1
/* Get number of cpus gathered from DT. */
adrp x3, cpu_count
add x3, x3, :lo12:cpu_count
ldr w3, [x3]
/* Prevent number of CPUs to be higher than supported by platform. */
cmp w3, #MAX_CPUS
bhi .
/* x0 points to first cpu in cpus array. */
adrp x0, cpus
add x0, x0, :lo12:cpus
/* Get current core affinity. */
get_core_affinity x1, x2
/* Dead stop here if no more cpu. */
0: cbz w3, 0b
sub w3, w3, #1
/* Get cpu id pointed to by x0 in cpu array. */
ldr x2, [x0, CPU_ID]
If I have defined this 3rd physical CPU in hafnium manifest then hafniu proceed further from above code. But then will hit plat_psci_cpu_resume and eventually it will abort with following check
CHECK(vcpu_index < vm->vcpu_count);
cpu_init:
/* Call into C code, x0 holds the CPU pointer. */
bl cpu_main
/* Run the vCPU returned by cpu_main. */
bl vcpu_restore_all_and_run
it looks like hafnium expects >= the number of physical Pes running at non-secure side to be defined in SPMC manifest file. Also it expects the same number of VCPUs to be defined in manifest file.
but my understanding is, there could be number of PEs running at non-secure side could be greater than number of Pes/VCPUs at secure side.
But from the code flow of hafnium, I don't think it supports that.
Regards,
Oza.
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023.
Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…).
Closing out the release takes around 6-10 working days after the code freeze.
Preparations tasks for v2.10 release should start in coming month.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Thanks & Regards,
Olivier.
