On Thu, May 1, 2025, at 10:12, Arnd Bergmann wrote:
On Thu, May 1, 2025, at 02:56, Dan Williams wrote:
Arnd Bergmann wrote:
On Wed, Apr 30, 2025, at 04:46, Dan Williams wrote:
The other bit of the puzzle is that memremap() on x86 silently falls back to ioremap() for non-RAM pages. This was originally added in 2008 commit e045fb2a988a ("x86: PAT avoid aliasing in /dev/mem read/write"). I'm not sure what happened exactly, but I suspect that the low 1MB was already mapped at the time through a cached mapping, while the PCI MMIO hole was perhaps not mapped. On x86-32, the 32-bit PCI BAR area should not be included here (since it's above high_memory), but the 16MB hold may be.
Following up myself after thinking about it some more: if we remove both the <1MB special case and the memremap() hack on x86-64 but leave both for x86-32, that would also avoid the cases that break CC guests, right and make x86-64 behave exactly like the other architectures, right?
If there is software that still relies on those hacks, it's probably very old, and more likely to be on 32-bit systems. There are many references to /dev/mem in Debian codesearch [1], but it's usually related to pre-PCIe graphics (svgalib, XFree86, uvesafb/v86), or it's memory-only accesses that rely on !CONFIG_STRICT_DEVMEM to read kernel structures.
Arnd
[1] https://codesearch.debian.net/search?q=%2Fdev%2Fmem&literal=1&perpkg...