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

On Tue, 2026-08-04 at 12:36 +0200, Arnd Bergmann wrote:
> On Tue, Aug 4, 2026, at 09:13, Heiko Carstens wrote:
> > On Mon, Aug 03, 2026 at 10:09:08PM +0200, Danilo Krummrich wrote:
> > > On Mon Aug 3, 2026 at 9:56 PM CEST, Arnd Bergmann wrote:
> > > > In theory you should be able to use rust code without PCI MMIO
> > > > support, but I can't see any practical downsides to making rust
> > > > 'depends on HAS_MMIO' to avoid having to add those #ifdef.
> > >=20
> > > I think the implications should be minor without making Rust depend o=
n
> > > CONFIG_HAS_IOMEM.
> > >=20
> > > I just sent out a fix [1]; the only annoying part is [2], but we shou=
ld change
> > > those doc-tests anyway. For the one in rust/kernel/io.rs we already d=
id in
> > > driver-core-next.
> > >=20
> > > [1] https://lore.kernel.org/driver-core/20260803200249.3494259-1-dakr=
@kernel.org/
>=20
> This looks like you still provide the rust version of ioremap(),
> turning what is supposed to be a link failure into a runtime
> error.
>=20
> > I'm wondering if it would make sense to make HAS_IOMEM always available
> > on s390, even though it doesn't make too much sense without PCI.
> > But at least it would make s390 again a bit less special.
>=20
> I see that with CONFIG_PCI=3Dy, s390 already falls back to
> generic_ioremap_prot() and just maps any phys_addr_t into the
> page table as PAGE_KERNEL, regardless of whether this is an MMIO
> address or not.
>=20
> The simple change below would just extend that behavior to !PCI
> and make that consistent with CONFIG_PCI=3Dy on machines without
> actual PCI hardware. Of course any code that might rely on this
> is now a bug that likely never gets caught at build time.
>=20
> This still relies on implementing the __raw_* helpers as nop
> to have the same behavior as the PCI=3Dy version, as the generic
> version would just end up dereferencing the invalid pointers.
>=20
>      Arnd

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. Sadly, without working on the non-MIO one still really
can't use memremap().

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.

Thanks,
Niklas