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

[Marc Zyngier]

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?

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

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