Skip to content

fix(aarch64): re-apply CLIDR_EL1 after PSCI CPU_ON - #6141

Open
BetterAndBetterII wants to merge 2 commits into
firecracker-microvm:mainfrom
BetterAndBetterII:cursor/aarch64-clidr-psci-cpu-on-38aa
Open

fix(aarch64): re-apply CLIDR_EL1 after PSCI CPU_ON#6141
BetterAndBetterII wants to merge 2 commits into
firecracker-microvm:mainfrom
BetterAndBetterII:cursor/aarch64-clidr-psci-cpu-on-38aa

Conversation

@BetterAndBetterII

Copy link
Copy Markdown

Secondary vCPUs are created powered-off and started via PSCI CPU_ON. KVM then resets the target and restores a fabricated CLIDR_EL1, so only vCPU0 keeps the DT-consistent override. Guests see an asymmetric cache topology and Linux disables load balancing.

Store the boot-time CLIDR override and write it again after KVM_ARM_VCPU_INIT and when a secondary becomes runnable, so all vCPUs keep the same cache topology.

Fixes #6139

Secondary vCPUs are created powered-off and started via PSCI CPU_ON,
which makes KVM reset the target and restore a fabricated CLIDR_EL1.
Store the DT-consistent override and write it again after vCPU reset
and when a secondary becomes runnable, so all vCPUs keep the same
cache topology.

Signed-off-by: Chiikawa <chiikawa0077@gmail.com>

Co-authored-by: Yuzhong Zhang <BetterAndBetterII@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] aarch64: CLIDR_EL1 override lost on secondary vCPUs, breaking guest load balancing

3 participants