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

On Tue, Aug 4, 2026, at 14:21, Niklas Schnelle wrote:
>
> I think there is also an interesting interaction with memremap(). 
> That calls ioremap() under some circumstances and it's a known issue that 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.

Right, that is an interesting one, as there are somewhat conflicting
requirements:

- 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?).

- 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.

> 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.

This would not help with either memremap() or the !CONFIG_HAS_MMIO
issue though, right?

       Arnd