[PATCH] KVM: arm64: fix MPIDR to vcpu index cache to support vcpu change at runtime

Marc Zyngier maz at kernel.org
Fri Dec 1 04:15:56 PST 2023


Hi Ting,

On Fri, 01 Dec 2023 10:48:54 +0000,
"liting (Q)" <liting8 at huawei.com> wrote:
> 
> On 2023/11/30 3:18, Marc Zyngier wrote:
> > On Tue, 28 Nov 2023 13:54:02 +0000,
> > l00313349 <liting8 at huawei.com> wrote:
> >> From: Ting Li <liting8 at huawei.com>
> >> 
> >> Consider vcpu change at runtime, for example online_vcpus is 8,
> >> but only start 2 vcpu threads, MPIDR to vcpu index 0 may be overwrited
> >> and vm hangs. When start other vcpu threads, cache will be outdated
> >> and always get mismatch.
> > If userspace creates two vcpus with the same vcpu_id, and therefore
> > the same MPIDR value, that's userspace's problem. Don't do that.
> > 
> > Why should we do anything else?
> > 
> > 	M.
> Hi Marc,
> Thanks for your reply. Maybe you have misunderstanding about it.
> The problem is not two vcpus with the same vcpu_id, but different vcpu_id
> have the same MPIDR value in some situation such as vcpu hotplug.

But that's *wrong*. The whole point of MPIDR is that it distinguishes
between CPUs. By definition, MPIDR *must* be unique in the system, and
if you have two vcpus with the same MPIDR, you have a broken VM.

> In my case, total vcpu count is 8 but only start 2 vcpu at the beginning,
> then vcpu_id 2-7 will get the same MPIDR value 0 with vcpu_id 0, so
> index 0 will be overwrited to vcpu_id 7.

And that's wrong as per the letter of the architecture. Here's what it
says: "In an implementation containing multiple PEs, each PE is
identified by a unique affinity value reported by MPIDR_EL1{Aff3,
Aff2, Aff1, Aff0}" (D12.4 Attributability).

You don't have a case here. You are creating a VM that is in complete
violation of the architecture. It is your choice to do so, but don't
expect things to work.

> Please check, thanks.

I did.

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list