Re: `io{re,un}map()` build error in s390 under `!CONFIG_HAS_IOMEM`

On Tue, 2026-08-04 at 17:52 +0200, Arnd Bergmann wrote:
> On Tue, Aug 4, 2026, at 14:21, Niklas Schnelle wrote:
> >=20
> > I think there is also an interesting interaction with memremap().=20
> > That calls ioremap() under some circumstances and it's a known issue th=
at on
> > s390 memremap() will work if the PCI memory-I/O (MIO) instructions are
> > enabled (e.g. on modern LPARs) because then ioremap() actually maps,
> > but won't work if they aren't enabled. With your proposal it would also
> > work for !PCI.
>=20
> Right, that is an interesting one, as there are somewhat conflicting
> requirements:
>=20
> - On PCI MMIO areas, memremap() and memremap_wt() should return a
>   normal kernel pointer that can be dereferenced, e.g. for
>   option ROM contents for a framebuffer console. This can't work
>   on non-MIO guests but might work on MIO depending on which
>   instructions are allowed those mappings (I can never quite
>   remember how this part works on z, does this have to use
>   pcistgi or does a normal aligned load/store work as well?).

You still have to use pcistgi/pcilgi/pcistbi normal aligned
loads/stores will fail as the physical address is beyond the memory
limit. On the other hand the PCI instructions can't access normal
memory. So you when using memremap() you'd have to know which kind of
memory you're remapping and use the right accessors.

>=20
> - On areas that are backed by physical RAM but not part of the
>   kernel memory (something like z/VM DCSS) should be mapped
>   using memremap(), which would fail with the current !MIO
>   implementation. On x86 and arm, this is done for mapping
>   firmware blobs, but I don't think anything tries to do
>   this on s390.
>   Right now, not having memremap() defined on !PCI configs is
>   the one thing that lets you know if some non-PCI code ever
>   start using it, other than crashing a non-MIO guest.
>=20
> > I actually have a prototype lying around where ioremap() always remaps
> > by mapping the address cookies much like we do for user-space access
> > via the s390 specific MMIO syscalls and then doing a page table walk in
> > the accessors for the case where we don't have PCI MIO support. That
> > would also allow us to implement the s390 MMIO syscall via
> > generic_access_phys() getting rid of quite nasty inline assembly and
> > over 300 lines removed in total. On the other hand it would cause
> > overhead for non-MIO systems and sadly this currently includes all KVM
> > and z/VM guests which is why it remains on my prototype pile. I haven't
> > actually been able to measure the overhead but clearly more work is
> > done.
>=20
> This would not help with either memremap() or the !CONFIG_HAS_MMIO
> issue though, right?
>=20
>        Arnd

I think it would help with memremap() because it would mean that when
used on normal memory and accessed with normal loads/stores memremap()
works and when used on PCI BAR / MIO addresses and accessed by I/O
accessors it would also work. So it should behave the same no matter if
memory-I/O is available.

Thanks,
Niklas