[PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Zhou Wang]

On 2025/9/26 16:57, Marc Zyngier wrote:
> On Fri, 26 Sep 2025 08:15:16 +0100,
> Zhou Wang <wangzhou1 at hisilicon.com> wrote:
>>
>> On 2025/9/19 23:52, Marc Zyngier wrote:
>>> On Mon, 01 Sep 2025 11:55:49 +0100,
>>> Zhou Wang <wangzhou1 at hisilicon.com> wrote:
>>>>
>>>> On 2025/8/25 10:39, Zhou Wang wrote:
>>>>> As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
>>>>> writable support, then add HiSilicon erratum 162200802.
>>>>>
>>>>> Erratum number should be 162200802, make a mistake in V1, so fix it as
>>>>> well.
>>>>>
>>>>> Zhou Wang (4):
>>>>>   KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
>>>>>   KVM: arm64: selftests: Add test for GICD.num_LPIs
>>>>>   Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
>>>>>     description
>>>>>   ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802
>>>>
>>>> Hi Marc and Oliver,
>>>>
>>>> As the discussion in V1 series, this series firstly adds GICD.num_LPIs
>>>> writable support, then add erratum patch.
>>>
>>> Given the state of this HW (as per [1]), I'd rather we start by
>>> working out the strategy at the GIC level, rather than exposing stuff
>>> to userspace before we agree on a way to make it work in the kernel.
>>
>> This bug is in GICv4.0([1] is in GICv4.1), and seems having a clear way
>> to fix. How about merging this fix firstly, then continue to try to solve [1]?
> 
> No. It has to be worked out the other way around, because this is
> introducing a new userspace ABI, and adding new ABIs to cope with
> design bugs is not really acceptable, specially when you have a
> perfectly good way to deal with the issue (don't enable GICv4).
> 
> I also don't understand your 4.0 vs 4.1 point. This is for HIP10 and
> HIP10C. [1] clearly says that both HIP9/10/10C are GICv4.1
> implementations. So what is what here?

HIP09/10/10C support both 4.0 and 4.1, which could be selected by a BIOS
switch.

> 
> I'm mildly annoyed at being spoon-fed bits of errata with
> contradicting statements instead of being given the full picture for
> what looks like an implementation train-wreck. From what I can see,
> these implementations are broken, and not worth salvaging. There is a
> perfectly valid workaround that keeps VMs running without any extra
> change. Why can't you simply use that?
> 
> Thanks,
> 
> 	M.
> 
> [1] https://lore.kernel.org/r/20250909110615.129179-1-wangzhou1@hisilicon.com
>