On Tue, 07 May 2024 20:29:12 +0100,
Oliver Upton <oliver.upton@xxxxxxxxx> wrote:
>
> A particularly annoying userspace could create a vCPU after KVM has
> computed mpidr_data for the VM, either by racing against VGIC
> initialization or having a userspace irqchip.
>
> In any case, this means mpidr_data no longer fully describes the VM, and
> attempts to find the new vCPU with kvm_mpidr_to_vcpu() will fail. The
> fix is to discard mpidr_data altogether, as it is only a performance
> optimization and not required for correctness. In all likelihood KVM
> will recompute the mappings when KVM_RUN is called on the new vCPU.
>
> Note that reads of mpidr_data are not guarded by a lock; promote to RCU
> to cope with the possibility of mpidr_data being invalidated at runtime.
>
> Fixes: 54a8006d0b49 ("KVM: arm64: Fast-track kvm_mpidr_to_vcpu() when mpidr_data is available")
> Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx>
> ---
> arch/arm64/kvm/arm.c | 49 ++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 40 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index c4a0a35e02c7..0d845131a0e0 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -195,6 +195,22 @@ void kvm_arch_create_vm_debugfs(struct kvm *kvm)
> kvm_sys_regs_create_debugfs(kvm);
> }
>
> +static void kvm_destroy_mpidr_data(struct kvm *kvm)
> +{
> + struct kvm_mpidr_data *data;
> +
> + mutex_lock(&kvm->arch.config_lock);
> +
> + data = rcu_dereference_raw(kvm->arch.mpidr_data);
I'm slightly worried by this. Why can't we use the "cooked" version?
If anything I'd like to see a comment about this, as it is usually
frowned upon.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
