linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
Cc: "Carsten Haitzler" <Carsten.Haitzler@arm.com>,
	"David Airlie" <airlied@linux.ie>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Will Deacon" <will.deacon@arm.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Huang, Ray" <Ray.Huang@amd.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Zhang, Jerry" <Jerry.Zhang@amd.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"Bernhard Rosenkränzer" <Bernhard.Rosenkranzer@linaro.org>
Subject: Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
Date: Wed, 16 Jan 2019 08:47:41 +0100	[thread overview]
Message-ID: <CAKv+Gu8_0HjPsT2ne-uCtxRt=2CE_tLGY6wo9xafC5SmJOGRKA@mail.gmail.com> (raw)
In-Reply-To: <9dc27cbf-e109-0c32-fc92-6fce1b224cda@amd.com>

On Wed, 16 Jan 2019 at 08:36, Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt:
> > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
> >>>> As far as I know Power doesn't really supports un-cached memory at all,
> >>>> except for a very very old and odd configuration with AGP.
> >>> Hopefully Michael/Ben can elaborate here, but I was under the (possibly
> >>> mistaken) impression that mismatched attributes could cause a machine-check
> >>> on Power.
> >> That's what I've always been told, but I can't actually find where it's
> >> documented, I'll keep searching.
> >>
> >> But you're right that mixing cached / uncached is not really supported,
> >> and probably results in a machine check or worse.
> >   .. or worse :) It could checkstop.
>
> Not sure if that would be so bad, it would at least give us a clear
> indicator that something is wrong instead of silently corrupting data.
>
> > It's also my understanding that on ARM v7 and above, it's technically
> > forbidden to map the same physical page with both cached and non-cached
> > mappings, since the cached one could prefetch (or speculatively load),
> > thus creating collisions and inconsistencies. Am I wrong here ?
>
> No, but you answer the wrong question.
>
> See we don't want to have different mappings of cached and non-cached on
> the CPU, but rather want to know if a snooped DMA from the PCIe counts
> as cached access as well.
>
> As far as I know on x86 it doesn't, so when you have an un-cached page
> you can still access it with a snooping DMA read/write operation and
> don't cause trouble.
>

I think it is the other way around. The question is, on an otherwise
cache coherent device, whether the NoSnoop attribute set by the GPU
propagates all the way to the bus so that it bypasses the caches.

On x86, we can tolerate if this is not the case, since uncached memory
accesses by the CPU snoop the caches as well.

On other architectures, uncached accesses go straight to main memory,
so if the device wrote anything to the caches we won't see it.

So to use this optimization, you have to either be 100% sure that
NoSnoop is implemented correctly, or have a x86 CPU.

> > The old hack of using non-cached mapping to avoid snoop cost in AGP and
> > others is just that ... an ugly and horrible hacks that should have
> > never eventuated, when the search for performance pushes HW people into
> > utter insanity :)
>
> Well I agree that un-cached system memory makes things much more
> complicated for a questionable gain.
>
> But fact is we now have to deal with the mess, so no point in
> complaining about it to much :)
>

Indeed. I wonder if we should just disable it altogether unless CONFIG_X86=y

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-16  7:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  7:28 [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM Ard Biesheuvel
2019-01-10  8:36 ` Zhang, Jerry(Junwei)
2019-01-10  8:36 ` Koenig, Christian
2019-01-10  9:34 ` Michel Dänzer
2019-01-14 10:53   ` Ard Biesheuvel
2019-01-14 11:38     ` Koenig, Christian
2019-01-14 17:32       ` Ard Biesheuvel
     [not found]         ` <9f956898-7973-98ee-6bf1-e1d445e9d365@amd.com>
2019-01-14 19:13           ` Will Deacon
2019-01-14 19:21             ` Koenig, Christian
2019-01-14 19:35               ` Will Deacon
2019-01-15 11:31                 ` Michael Ellerman
2019-01-16  0:33                   ` Benjamin Herrenschmidt
2019-01-16  7:35                     ` Koenig, Christian
2019-01-16  7:47                       ` Ard Biesheuvel [this message]
2019-01-17  6:07                         ` Benjamin Herrenschmidt
2019-01-17  8:02                           ` Ard Biesheuvel
2019-01-17  5:59                       ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKv+Gu8_0HjPsT2ne-uCtxRt=2CE_tLGY6wo9xafC5SmJOGRKA@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=Bernhard.Rosenkranzer@linaro.org \
    --cc=Carsten.Haitzler@arm.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Jerry.Zhang@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=airlied@linux.ie \
    --cc=benh@kernel.crashing.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    --cc=mpe@ellerman.id.au \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).