Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 8 Aug 2019 12:00:31 +0200
From:   Christoph Hellwig <hch@lst.de>
To:     Rob Clark <robdclark@chromium.org>
Cc:     Christoph Hellwig <hch@lst.de>, Rob Clark <robdclark@gmail.com>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <maxime.ripard@bootlin.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Allison Randal <allison@lohutok.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-arm-kernel@lists.infradead.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] drm: add cache support for arm64
Message-ID: <20190808100031.GA32658@lst.de>
References: <20190805211451.20176-1-robdclark@gmail.com> <20190806084821.GA17129@lst.de> <CAJs_Fx6eh1w7c=crMoD5XyEOMzP6orLhqUewErE51cPGYmObBQ@mail.gmail.com> <20190806155044.GC25050@lst.de> <CAJs_Fx6uztwDy2PqRy3Tc9p12k8r_ovS2tAcsMV6HqnAp=Ggug@mail.gmail.com> <20190807062545.GF6627@lst.de> <CAJs_Fx7tqbr_gqRdqJEwOcRFReP0DqZzOu11Dxhxkp8+PygUQw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJs_Fx7tqbr_gqRdqJEwOcRFReP0DqZzOu11Dxhxkp8+PygUQw@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Aug 07, 2019 at 09:09:53AM -0700, Rob Clark wrote:
> > > (Eventually I'd like to support pages passed in from userspace.. but
> > > that is down the road.)
> >
> > Eww.  Please talk to the iommu list before starting on that.
> 
> This is more of a long term goal, we can't do it until we have
> per-context/process pagetables, ofc.
> 
> Getting a bit off topic, but I'm curious about what problems you are
> concerned about.  Userspace can shoot it's own foot, but if it is not
> sharing GPU pagetables with other processes, it can't shoot other's
> feet.  (I'm guessing you are concerned about non-page-aligned
> mappings?)

Maybe I misunderstood what you mean above, I though you mean messing
with page cachability attributes for userspace pages.  If what you are
looking into is just "standard" SVM I only hope that our APIs for that
which currently are a mess are in shape by then, as all users currently
have their own crufty and at least slightly buggy versions of that.  But
at least it is an issue that is being worked on.

> > So back to the question, I'd like to understand your use case (and
> > maybe hear from the other drm folks if that is common):
> >
> >  - you allocate pages from shmem (why shmem, btw?  if this is done by
> >    other drm drivers how do they guarantee addressability without an
> >    iommu?)
> 
> shmem for swappable pages.  I don't unpin and let things get swapped
> out yet, but I'm told it starts to become important when you have 50
> browser tabs open ;-)

Yes,  but at that point the swapping can use the kernel linear mapping
and we are going into aliasing problems that can disturb the cache.  So
as-is this is going to problematic without new hooks into shmemfs.

> >  - then the memory is either mapped to userspace or vmapped (or even
> >    both, althrough the lack of aliasing you mentioned would speak
> >    against it) as writecombine (aka arm v6+ normal uncached).  Does
> >    the mapping live on until the memory is freed?
> 
> (side note, *most* of the drm/msm supported devices are armv8, the
> exceptions are 8060 and 8064 which are armv7.. I don't think drm/msm
> will ever have to deal w/ armv6)

Well, the point was that starting from v6 the kernels dma uncached
really is write combine.  So that applied to v7 and v8 as well.