irqchip/gic-v3-its:【ITS-0528】 Probe ITS page size for all GITS_BASERn registers

[Fred Kimmy]

[Bug Description]
The GICv3 ITS driver assumes that once it has latched on a page size for
a given BASER register, it can use the same page size as the maximum
page size for all subsequent BASER registers.

Although it worked so far, nothing in the architecture guarantees this,
and Nianyao Tang hit this problem on some undisclosed implementation.

Let's bite the bullet and probe the the supported page size on all BASER
registers before starting to populate the tables. This simplifies the
setup a bit, at the expense of a few additional MMIO accesses.

[Steps to Reproduce]
1)
2)
3)

[Actual Results]

[Expected Results]

[Reproducibility]

[Additional information]
(Firmware version, kernel version, affected hardware, etc. if required):

[Resolution]

irqchip/gic-v3-its: Probe ITS page size for all GITS_BASERn registers

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.7-rc7&id=d5df9dc96eb7423d3f742b13d5e1e479ff795eaa

[Ike Panhc (ikepanhc)]

d5df9dc96eb7 irqchip/gic-v3-its: Probe ITS page size for all GITS_BASERn registers

In mainline kernel since 5.7-rc1.

[Ike Panhc (ikepanhc)]

I have same conflict when cherry-pick to bionic and focal kernel. I will try to find if there are any other patches needed to cherry-pick or any other way to solve the conflict.

[dann frazier (dannf)]

@Xinwei: This mentions the impact is for an undisclosed implementation. Can you confirm if it impacts Hi1616 or Hi1620? Can you also confirm if this impacts the Ubuntu kernel, which as you know is 4K pages?

[Ike Panhc (ikepanhc)]

I can not reproduce this issue in original report[1] on either d05[2] or d06[3]. Is this a problem for d05/d06?

--
[1] https://lore<email address hidden>/

[2]
$ dmesg | grep 'Virtual CPUs'
[ 0.000000] ITS@0x000000004c000000: allocated 65536 Virtual CPUs @17da280000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x000000006c000000: allocated 65536 Virtual CPUs @17da380000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x00000000c6000000: allocated 65536 Virtual CPUs @17d8000000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x00000008c6000000: allocated 65536 Virtual CPUs @17d8080000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x000004004c000000: allocated 65536 Virtual CPUs @17d8100000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x000004006c000000: allocated 65536 Virtual CPUs @17d8180000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x00000400c6000000: allocated 65536 Virtual CPUs @17d8200000 (flat, esz 8, psz 4K, shr 1)
[ 0.000000] ITS@0x00000408c6000000: allocated 65536 Virtual CPUs @17d8280000 (flat, esz 8, psz 4K, shr 1)

[3]
$ dmesg | grep 'Virtual CPUs'
[ 0.000000] ITS@0x0000000202100000: allocated 65536 Virtual CPUs @3f7e500000 (flat, esz 16, psz 4K, shr 1)
[ 0.000000] ITS@0x0000200202100000: allocated 65536 Virtual CPUs @203f7e100000 (flat, esz 16, psz 4K, shr 1)

[Fred Kimmy (kongzizaixian)]

[ 0.000000] Booting Linux on physical CPU 0x0300000000 [0x480fd020]
[ 0.000000] Linux version 4.18.0 (linweikai@ubuntu) (gcc version 5.4.0 201606
09 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12)) #1 SMP Mon May 25 16:27:14 CST 2020
[ 0.000000] earlycon: pl11 at MMIO32 0x0000000614080000 (options '')
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: ACPI 2.0=0x3a360000 MEMATTR=0x3ef5f018 MEMRESERVE=0x3a6bb
018
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x000000003A360000 000024 (v02 HISI )
[ 0.000000] ACPI: XSDT 0x000000003A350000 00004C (v01 HISI HIP09 0000000
0 ISIH 20151124)
[ 0.000000] ACPI: FACP 0x000000003A2B0000 000114 (v06 HISI HIP09 0000000
0 HISI 20151124)
[ 0.000000] ACPI: DSDT 0x000000003A120000 0031EA (v02 HISI HIP09 0000000
0 INTL 20181213)
[ 0.000000] ACPI: GTDT 0x000000003A150000 00007C (v02 HISI HIP09 0000000
0 HISI 20151124)
[ 0.000000] ACPI: APIC 0x000000003A140000 0000F0 (v01 HISI HIP09 0000000
0 HISI 20151124)
[ 0.000000] ACPI: MCFG 0x000000003A130000 00003C (v01 HISI HIP09 0000000
0 HISI 20151124)
[ 0.000000] ACPI: IORT 0x000000003A110000 0010F8 (v00 HISI HIP09 0000000
0 INTL 20181213)
[ 0.000000] ACPI: NUMA: Failed to initialise from firmware
[ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x000000003fbfffff
]
[ 0.000000] NUMA: NODE_DATA [mem 0x3fbae600-0x3fbaffff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x000000003fbfffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000039f6ffff]
[ 0.000000] node 0: [mem 0x0000000039f70000-0x0000000039fcffff]
[ 0.000000] node 0: [mem 0x0000000039fd0000-0x000000003a0bffff]
[ 0.000000] node 0: [mem 0x000000003a0c0000-0x000000003a10ffff]
[ 0.000000] node 0: [mem 0x000000003a110000-0x000000003a15ffff]
[ 0.000000] node 0: [mem 0x0000000...

[Fred Kimmy (kongzizaixian)]

this new hardware comment 5# can reproduce it, can you merge it and provide a kernel branch? I will help you to test it.

[Ike Panhc (ikepanhc)]

Judge from kernel output in #5. The hardware which is able to reproduce this issue is not d05 nor d06. I don't think this patch is SRU qualified.

[Andrew Cloke (andrew-cloke)]

Marking as incomplete while waiting for evidence that this patch impacts either Hi1616 or Hi1620.

[Fred Kimmy (kongzizaixian)]

=>Marking as incomplete while waiting for evidence that this patch impacts either Hi1616 or Hi1620.
now this have hardware will not reproduce it. We can help you to test it.

[Taihsiang Ho (tai271828)]

Please note the upstream commit is now also in Focal hwe-5.8 kernel tree (tag Ubuntu-hwe-5.8-5.8.0-25.26_20.04.1)

[Ike Panhc (ikepanhc)]

Patch hits 20.04.2 HWE kernel.