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

["Arnd Bergmann" <arnd@arndb.de>]

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.

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