CPU validation

[Rivanfirdausa]

Hi Bao Hypervisor Team,

I'm running a mixed-criticality system on a Toradex Verdin iMX8M Plus (4x Cortex-A53). I have strictly partitioned the physical cores using the cpu_affinity bitmask:

VM 1 (AGL Linux): .cpu_affinity = 0b000011 (pCPU 0, 1)

VM 2 (RT Linux): .cpu_affinity = 0b001100 (pCPU 2, 3)

The Issue:
Inside VM 2, cat /proc/cpuinfo still shows processor : 0 and processor : 1.

If I define the CPUs in VM 2's DTS as cpu@2 and cpu@3 to match the physical hardware, Linux panics (Data Abort at kthreadd) because it expects to boot on logical CPU 0. Reverting the DTS to cpu@0 and cpu@1 fixes the boot, but leaves the Guest OS "blind" to its true physical core allocation.

Questions:

Is it Bao's strict intended design to spoof the MPIDR so every Guest OS sees its vCPUs starting from 0, regardless of physical affinity?

Is there any supported way (e.g., via PSCI) to expose the actual physical core IDs to the Guest OS for functional safety/documentation purposes?

[josecm]

Inside VM 2, cat /proc/cpuinfo still shows processor : 0 and processor : 1.

Is it Bao's strict intended design to spoof the MPIDR so every Guest OS sees its vCPUs starting from 0, regardless of physical affinity?

In sum, yes.

This is waht is expected. Bao always fills in VMPIDR_EL2 in order for the number of vCPUs part of the VM. So in a VM you will never have a VM with vcpu id 2, without 1 and 0. To do that you'll need to change the code to pass through the VMPIDR_EL2. But a warning: that will likely break bao's code in other components such as vgic ou psci.

Is there any supported way (e.g., via PSCI) to expose the actual physical core IDs to the Guest OS for functional safety/documentation purposes?

No, but if you give us a good use case for this we can probably add this feature or hopefully you could contribute it (we'll help 😉). Please raise a issue with a feature request and explain your rationale and why this is useful for real-world use cases.

[Rivanfirdausa]

Thanks for confirming the VMPIDR_EL2 behavior. Exposing the pCPU IDs without breaking existing vGIC/PSCI logic would be highly beneficial for Automotive Mixed-Criticality Systems (MCS) and Software-Defined Vehicle (SDV) architectures.

Two main real-world use cases:

1. Hardware Fault Traceability: In an RT Linux partition, mapping OS-level errors back to the exact physical silicon is critical for functional safety and diagnostic logging.

2. Future-proofing for Asymmetric Topologies: While my current setup uses a symmetric Toradex Verdin iMX8M Plus, SDV architectures scaling to big.LITTLE SoCs will require the Guest OS to know the true physical topology for power-aware scheduling. This is lost if all vCPUs start at 0.

Instead of modifying VMPIDR_EL2, would it be acceptable to either inject a custom property into the guest's DTB (e.g., under /chosen) or provide a custom Bao hypercall to query the mapping?

I would love to contribute this feature. Could you point me to the relevant files in the codebase to explore the DTB injection or hypercall approach?

Best regards,

[josecm]

That makes sense. I am wondering if this should be just done with a field in the vm_config struct to expose the real cpu id to the VM. Then we'd need to adapt all points in the code where the vcpuid<->mpidr mapping for it. In this way, there wouldn't need to be any real modification to linux, just the adaptation of the device tree.

[josecm]

Could you start by creating the feature request so we can have it in backlog?