[PATCH] [RFC] etnaviv: Don't apply pgprot_noncached for ETNA_BO_UNCACHED

[Guido Günther]

Hi,
On Fri, Sep 28, 2018 at 11:45:58PM +0200, Lucas Stach wrote:
> Hi Guido,
> 
> Am Freitag, den 14.09.2018, 14:10 +0200 schrieb Guido Günther:
> > Hi,
> > On Fri, Sep 14, 2018 at 11:27:08AM +0200, Lucas Stach wrote:
> > > Hi Guido,
> > > 
> > > Am Donnerstag, den 13.09.2018, 20:00 +0200 schrieb Guido Günther:
> > > > Hi,
> > > > On arm64 userspace does not seem to be able to mmap memory marked as
> > > > pgprot_noncached(nGnRnE) or pgprot_device(nGnRE).
> > > 
> > > What's the issue with a normal uncached mapping on ARM64? Is the
> > > mapping not set up at all, or do you get aborts or something?
> > 
> > Userspace gets SIGBUS during memset like below:
> > 
> >   bo = etna_bo_new(dev, 0x100, flags);
> >   buf = etna_bo_map(bo);
> >   etna_bo_cpu_prep(bo, DRM_ETNA_PREP_WRITE);
> >   memset(buf, 0, 0x100);
> 
> That is kind of expected with uncached being translated to a nG
> mapping. memset as implemented by glibc on ARM64 uses some tricks with
> unaligned loads/stores to avoid control flow, which depend on being
> able to merge overlapping requests in a gather buffer.
> 
> Having the uncached mapping as nGnR allows for usages such as signal
> pages, so I would like to avoid applying this patch if possible.
> Instead I would rather make the etnaviv UAPI more strict with regard to
> the memory attributes by demanding that userspace only uses UNCACHED
> for usages where the access alignment can be tightly controlled and
> must use WC or CACHED for any other usages. I'm not aware of any
> existing userspace (aside from the WIP GC7000 Mesa support) that would
> break due to such a change in the UAPI contract.

That makes sense. I've send out a patch to fix up the one occurrence in
etnaviv_shader as well:

    https://lists.freedesktop.org/archives/mesa-dev/2018-October/206131.html

Cheers,
 -- Guido