Re: `io{re,un}map()` build error in s390 under `!CONFIG_HAS_IOMEM`
"Arnd Bergmann" <[email protected]> Thu, 06 Aug 2026 15:44:13 +0200
| Newsgroups | org.kernel.vger.rust-for-linux,dev.linux.lists.driver-core,org.kernel.vger.linux-arch,org.kernel.vger.linux-s390 |
|---|---|
| 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