[PATCH] ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200803
Zhou Wang
wangzhou1 at hisilicon.com
Tue Jul 8 19:08:42 PDT 2025
On 2025/7/8 20:47, Marc Zyngier wrote:
> On Tue, 08 Jul 2025 13:05:24 +0100,
> Zhou Wang <wangzhou1 at hisilicon.com> wrote:
>>
>> On 2025/7/3 18:44, Marc Zyngier wrote:
>>> On Wed, 02 Jul 2025 10:57:13 +0100,
>>> Zhou Wang <wangzhou1 at hisilicon.com> wrote:
>>>>
>>>> However,migration between different KVMs will be broken :(
>>>> I am not sure that should we consider this case as well?
>>>
>>> This isn't optional. You cannot break migration on existing systems,
>>> and the only case that *must* break is to restore a VM that hasn't
>>> seen this limitation on a HW that enforces it.
>>
>> So the whole story is that we should let GICD_TYPE.num_LPIs as a
>> writable field, and set this field from VMM(e.g. QEMU). And it will
>> be failed if doing migration between VMs with different num_LPI
>> configurations.
>
> Note that on a non-broken system, setting num_LPIs to any value should
> always work.
>
>> After above done, this errata could be added.
>
> Which would be the only case where num_LPIs wouldn't be writable, and
> set to a fixed value.
>
> Note that an alternative would be to not have a kernel erratum, but to
> force num_LPIs from userspace when running on your platform. But that
> implies that: you have your own, non-upstream VMM, and that there is
> no opportunity for userspace to adversely impact the system as a whole.
Got it. Seems it is better to have this erratum in kernel.
>
>> Not sure my thought above is right? I will try to prepare a num_LPIs
>> writable patch if the direction is right.
>
> I think you got the gist of it.
Thanks a lot for the whole discussion, I will prepare the new patch.
Best,
Zhou
>
> Thanks,
>
> M.
>
More information about the linux-arm-kernel
mailing list