[PATCH 6.12.y 0/2] Fix ioremap of addresses above 4 GiB on x86-32 PAE

["Radek Marciňa" <github.unusual340@8alias.com>]

From: Radek Marciňa <github.unusual340@8alias.com>

Both patches are stable-only. In these trees the x86 PAGE_MASK is an
unsigned long, so "phys_addr &= PAGE_MASK" on a 64-bit physical address
clears bits 32-63. __ioremap_caller() and __early_ioremap() both do
this and map the low 32-bit alias of anything above 4 GiB.

Mainline is not affected since v6.13, where commit efe8419ae78d ("vdso:
Introduce vdso/page.h") and commit d4a65302dd84 ("vdso: Change
PAGE_MASK to signed on all 32-bit architectures") made PAGE_MASK signed
on 32-bit. Neither was marked for stable. They cannot go to 6.6.y and
older, which lack CONFIG_PAGE_SHIFT (added in v6.9). They do apply to
6.12.y, but together with the i915 build fix in commit 8fd236b00fc1
("drm: i915: Change fault type to unsigned long") they change PAGE_MASK
on every 32-bit architecture, the kind of change that caused the arm32
regression d4a65302dd84 itself fixes. So these patches cast at the two
affected sites instead.

Please apply to 6.12.y, 6.6.y, 6.1.y, 5.15.y and 5.10.y; the series
applies unchanged to all five. 6.18.y and later have the upstream
change.

Reproducer for 1/2: i386_defconfig plus CONFIG_HIGHMEM64G=y,
CONFIG_VIRTIO_PCI=y and CONFIG_HW_RANDOM_VIRTIO=y, booted with

  qemu-system-x86_64 -M q35 -accel kvm -cpu host,host-phys-bits-limit=44 \
    -m 5G -object memory-backend-ram,id=big,size=4G,share=on \
    -device ivshmem-plain,memdev=big -device virtio-rng-pci \
    -nic none -nographic -no-reboot \
    -kernel arch/x86/boot/bzImage -append "console=ttyS0 panic=-1"

The extra options get the virtio BARs above 4 GiB with SeaBIOS 1.16.2,
1.16.3 and 1.17.0. Since 1.16.3 SeaBIOS places 64-bit BARs high when
the guest has RAM above 4 GiB, which on q35 starts at -m 2816M; before
that only when the 32-bit window overflows, which the 4 GiB ivshmem BAR
forces. host-phys-bits-limit=44 keeps SeaBIOS 1.16.3 from placing them
beyond the 44 bits a PAE kernel can address.

On 6.12.115 the virtio BAR 4 at 0xe0100000000 gets mapped at physical
0x0-0x3fff (per /proc/vmallocinfo), the device ends up FAILED and the
log shows

  virtio_rng virtio0: probe with driver virtio_rng failed with error -2

With 1/2 applied the mapping is at 0xe0100000000, the device reaches
DRIVER_OK and /dev/hwrng returns data.

Nothing in a QEMU boot early-maps memory above 4 GiB on i386, so 2/2
was tested with a throwaway late_initcall that calls
early_memremap(0x100000123, 16) and prints slow_virt_to_phys() of the
result: 0x123 on 6.12.115, 0x100000123 with 2/2 applied.

Unmodified v7.3 in the same setup (CONFIG_X86_PAE=y in place of
CONFIG_HIGHMEM64G=y, which no longer exists) gets both mappings right.

Built with GCC 16.2.1, run on QEMU 11.1.2 with KVM.

Radek Marciňa (2):
  x86/ioremap: Sign-extend PAGE_MASK when aligning the physical address
  mm/early_ioremap: Sign-extend PAGE_MASK when aligning the physical
    address

 arch/x86/mm/ioremap.c | 2 +-
 mm/early_ioremap.c    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.56.0