On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +0000, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to MMIO space
is a well known bug of those ARM boards.
So as far as I know this is a hardware bug you are trying to workaround
here and I'm not 100% sure that this is correct.
No, this one's not a bug. The Device memory type used for iomem mappings is
*architecturally* defined to enforce properties like aligned accesses, no
speculation, no reordering, etc. If something wants to be treated more like
RAM than actual MMIO registers, then ioremap_wc() or ioremap_cache() is the
appropriate thing to do in general (with the former being a bit more
portable according to Documentation/driver-api/device-io.rst).
Well, qxl is a virtual device, so it *is* ram.
I'm wondering whenever qxl actually works on arm? As far I know all
virtual display devices with (virtual) pci memory bars for vram do not
work on arm due to the guest mapping vram as io memory and the host
mapping vram as normal ram and the mapping attribute mismatch causes
caching troubles (only noticeable on real arm hardware, not in
emulation). Did something change here recently?
Indeed, Armv8.4 introduced the S2FWB feature to cope with situations
like this - essentially it allows the hypervisor to share RAM-backed
pages with the guest without losing coherency regardless of how the
guest maps them.
Robin.