linux-kernel - Re: ioremap_uc() followed by set_memory_wc()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrX9xWtaw=1abNK1WSNgkAfR3b1gVpTeTC2Rn93SAJv4_w@mail.gmail.com>
Date:	Thu, 16 Apr 2015 12:19:05 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Andy Walls <awalls@...metrocast.net>
Cc:	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Roland Dreier <roland@...estorage.com>,
	Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
	Juergen Gross <jgross@...e.com>, X86 ML <x86@...nel.org>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Mike Marciniszyn <mike.marciniszyn@...el.com>,
	Suresh Siddha <sbsiddha@...il.com>,
	Ville Syrjälä <syrjala@....fi>,
	Borislav Petkov <bp@...e.de>,
	Sean Hefty <sean.hefty@...el.com>,
	Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Mel Gorman <mgorman@...e.de>,
	Vlastimil Babka <vbabka@...e.cz>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Toshi Kani <toshi.kani@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Davidlohr Bueso <dbueso@...e.de>, linux-media@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Apr 15, 2015 6:54 PM, "Andy Walls" <awalls@...metrocast.net> wrote:
>
> On Wed, 2015-04-15 at 17:58 -0700, Andy Lutomirski wrote:
> > On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls <awalls@...metrocast.net> wrote:
> > > On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
> > >> On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls <awalls@...metrocast.net> wrote:
> > >
> > >> >
> > >>
> > >> IMO the right solution would be to avoid ioremapping the whole bar at
> > >> startup.  Instead ioremap pieces once the driver learns what they are.
> > >> This wouldn't have any of these problems -- you'd ioremap() register
> > >> regions and you'd ioremap_wc() the framebuffer once you find it.  If
> > >> there are regions of unknown purpose, just don't map them all.
> > >>
> > >> Would this be feasible?
> > >
> > > Feasible? Maybe.
> > >
> > > Worth the time and effort for end-of-life, convential PCI hardware so I
> > > can have an optimally performing X display on a Standard Def Analog TV
> > > screen?   Nope. I don't have that level of nostalgia.
> > >
> >
> > The point is actually to let us unexport or delete mtrr_add.
>
> Understood.
>
>
> >   We can
> > either severely regress performance on ivtv on PAT-capable hardware if
> > we naively switch it to arch_phys_wc_add or we can do something else.
> > The something else remains to be determined.
>
> Maybe ioremap the decoder register area as UC, and ioremap the rest of
> the decoder region to WC. (Does that suck up too many PAT resources?

PAT resources are unlimited.

> Then add PCI reads following any sort of singleton PCI writes in the WC
> region.  I assume PCI rules about write postings before reads still
> apply when WC is set.
>

I think we need sfence, too, but that's easy.  We also lose the write
sizes.  That is, adjacent writes get combined.  Maybe that's okay.

> > >
> > > We sort of know where some things are in the MMIO space due to
> > > experimentation and past efforts examining the firmware binary.
> > >
> > > Documentation/video4linux/cx2341x/fw-*.txt documents some things.  The
> > > driver code actually codifies a little bit more knowledge.
> > >
> > > The driver code for doing transfers between host and card is complex and
> > > fragile with some streams that use DMA, other streams that use PIO,
> > > digging VBI data straight out of card memory, and scatter-gather being
> > > broken on newer firmwares.  Playing around with ioremapping will be hard
> > > to get right and likely cause something in the code to break for the
> > > primary use case of the ivtv supported cards.
> >
> > Ick.
>
> Yeah.
>
> > If the only thing that really wants WC is the esoteric framebuffer
> > thing,
>
> That appears to be it.
>
> >  could we just switch to arch_phys_wc_add and assume that no one
> > will care about the regression on new CPUs with ivtv cards?
>
> That's on the table in my mind.  Not sure if it is the friendliest thing
> to do to users.  Quite honestly though, modern graphics cards have much
> better ouput resolution and performance.  Anyone with a modern system
> really should be using one.  (i.e. MythTV gave up on support for PVR-350
> output for video playback years ago in May 2010.)
>
>
> BTW, my 2005 system with multiple conventional PCI slots in it shows a
> 'pat' flag in /proc/cpuinfo.  (AMD Athlon(tm) 64 X2 Dual Core Processor
> 4200+)  I didn't know it was considered "new". :)

Tons of CPUs have that ability, but we often turn it off due to errata
on older CPUs.

--Andy

>
> Regards,
> Andy
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/