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

"Arnd Bergmann" <[email protected]>
Newsgroups org.kernel.vger.linux-arch,dev.linux.lists.driver-core,org.kernel.vger.linux-s390,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Thu, Aug 6, 2026, at 15:25, Niklas Schnelle wrote:
> On Wed, 2026-08-05 at 17:56 +0200, Arnd Bergmann wrote:
>> On Wed, Aug 5, 2026, at 17:36, Niklas Schnelle wrote:
>> 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?

Indeed, I had not noticed that before, but you are right that
this goes directly to the page tables while the other variants of
memremap() go through architecture specific ioremap_prot(), which
may or may not create page table entries.

I think the reason is that there are a couple of architectures
(including non-MIO s390) that take a shortcut for normal
ioremap() that avoids actually mapping anything, e.g. mips
and related architectures have a fixed uncached mapping
of all MMIO space visible to kernel, while some alpha, m68k
powerpc, and s390 do something other than a pointer dereference
for MMIO.

     Arnd
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.