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

On Wed, 2026-08-05 at 17:56 +0200, Arnd Bergmann wrote:
> On Wed, Aug 5, 2026, at 17:36, Niklas Schnelle wrote:
> > On Tue, 2026-08-04 at 17:52 +0200, Arnd Bergmann wrote:
> > > On Tue, Aug 4, 2026, at 14:21, Niklas Schnelle wrote:
> > > - 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.
> 
> Ok, so memremap() by definition cannot work on s390 for regular
> PCI devices, since you are not allowed to use readl() etc on a
> kernel pointer returned by memremap(), only on an __iomem
> token returned by ioremap().
> 
> One important exception seems to be virtio_fs, which uses
> devm_memremap_pages() to map a virtio_shm_region, which in
> turn can come from a virtio-pci device but is backed by
> actual cached memory in the host instead of an emulated
> PCI memory BAR.

Interesting, do I see that right that devm_memremap_pages() and
memremap_pages() unlike plain memremap() does not utilize ioremap() and
thus isn't affected by our nopped ioreamp() when there is no-MIO?

> 
> > > This would not help with either memremap() or the !CONFIG_HAS_MMIO
> > > issue though, right?
> > 
> > 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.
> 
> Have you come across any users of memremap() that pass the
> kernel address into readl()/writel() rather than accessing
> them as pointers? This would of course work on arm and x86,
> but is still a violation of the linux/io.h interface definition
> and causes a compile-time warning with sparse. If these exist,
> I think we just need to change them to ioremap().
> 
>       Arnd

No, I'm not aware of any users of memremap() that would then use
readl()/writel() and I agree they really should be using ioremap() and
the use case doesn't really make sense I was just thinking about what
would technically work with the prototype I have.

Thanks,
Niklas