This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: framebuffer corruption due to overlapping stp instructions on arm64
- From: Mikulas Patocka <mpatocka at redhat dot com>
- To: Matt Sealey <neko at bakuhatsu dot net>
- Cc: Catalin Marinas <catalin dot marinas at arm dot com>, Russell King <linux at armlinux dot org dot uk>, Thomas Petazzoni <thomas dot petazzoni at free-electrons dot com>, Will Deacon <will dot deacon at arm dot com>, libc-alpha at sourceware dot org, linux-arm-kernel at lists dot infradead dot org, linux-kernel at vger dot kernel dot org
- Date: Fri, 3 Aug 2018 02:35:46 -0400 (EDT)
- Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
- References: <alpine.LRH.2.02.1808021242320.31834@file01.intranet.prod.int.rdu2.redhat.com> <CAHCPf3tFGqkYEcWNN4LaWThw_rVqT316pzLv6T7RfxwO-eZ0EA@mail.gmail.com>
On Thu, 2 Aug 2018, Matt Sealey wrote:
> The easiest explanation for this would be that the memory isn?t mapped
> correctly. You can?t use PCIe memory spaces with anything other than
> Device-nGnRE or stricter mappings. That?s just differences between the
> AMBA and PCIe (posted/unposted) memory models.
I've tried to use Device-nGnRE mapping and I've got unaligned access
traps. Gcc have store-merging pass so that it generates unaligned accesses
even in code that has none explicit unaligned accesses. Perhaps it would
be possible to recompile the kernel without the store-merging pass, but
recompiling all the userspace code is impossible.
Should we catch the unaligned access traps in the kernel and emulate them?
There are a lot of instructions that access memory in the ARMv8 ISA, so
the emulator would be quite complicated.
> Normal memory (cacheable or uncacheable, which Linux tends to call
> ?memory? and ?writecombine? respectively) is not a good idea.
>
> There are two options; make sure Links maps it?s framebuffer as Device
> memory, or the driver, or both - and make sure that only aligned
> accesses happen (otherwise you?ll just get a synchronous exception) and
> there isn?t a Normal memory alias.
>
> Alternatively, tell the PCIe driver that the framebuffer is in system
> memory
But how would the graphics card display from it? You'd have to
periodically copy the framebuffer from the system memory to the real
videoram. I'm not an expert in graphics drivers, I don't know if the
graphics drivers have this possibility.
> - you can map it however you like but there?ll be a performance
> hit if you start to use GPU acceleration, but a significant performance
> boost from the PoV of the CPU. Only memory accessed from the PCIe master
> interface (i.e. reads and writes generated by the card itself - telling
> the GPU to pull from system memory or other DMA) can be in Normal memory
> and this allows PCIe to be cache coherent with the right interconnect.
> The slave port on a PCIe root complex (i.e. CPU writes) can?t be used
> with Normal, or reorderable, and therefore your 2GB of graphics memory
> is going to be slow from the point of view of the CPU.
>
> To find the correct mapping you?ll need to know just how cache coherent
> the PCIe RC is...
>
> Ta,
> Matt
Mikulas