linux-kernel - RE: [PATCH v7 5/9] PCI: Add pci_iomap

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: <4985EFDD773FCB459EF7915D2A3621ADC03621@nice.asicdesigners.com>
Date:	Fri, 26 Jun 2015 16:24:27 +0000
From:	Casey Leedom <leedom@...lsio.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC:	Arnd Bergmann <arnd@...db.de>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Toshi Kani <toshi.kani@...com>,
	Andy Lutomirski <luto@...capital.net>,
	Juergen Gross <jgross@...e.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	linux-fbdev <linux-fbdev@...r.kernel.org>,
	Suresh Siddha <sbsiddha@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Dave Airlie <airlied@...hat.com>,
	Antonino Daplas <adaplas@...il.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"venkatesh.pallipadi@...el.com" <venkatesh.pallipadi@...el.com>,
	Stefan Bader <stefan.bader@...onical.com>,
	"ville.syrjala@...ux.intel.com" <ville.syrjala@...ux.intel.com>,
	David Vrabel <david.vrabel@...rix.com>,
	"Jan Beulich" <jbeulich@...e.com>,
	Roger Pau Monné <roger.pau@...rix.com>
Subject: RE: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants

  Thanks for looking into this Ben.  As it stands now, it seems as
if Write Combined mappings simply aren't supported and/or all
driver writers trying to utilize Write Combined mappings have to
"hand roll" their own solutions which really isn't supportable.

  One thing that might be considered is simply to treat the desire
to utilize the Write Combining hardware as a separate issue and
develop writel_wc(), writeq_wc(), etc.  Those could be defined
as legal only for Write Combined Mappings and would "do the
right thing" for each architecture.  The initial implementations
could simply be writel(), writeq(), etc. till each architecture'si
ssues were investigated and understood.

  Additionally, it would be very useful to have some sort of
predicate which could be used to determine if an architecture
supported Write Combining.  Our drivers would use this to
eliminate a wasteful attempt to use write combining on those
architectures where it didn't work.

Casey

________________________________________
From: Benjamin Herrenschmidt [benh@...nel.crashing.org]
Sent: Thursday, June 25, 2015 7:02 PM
To: Casey Leedom
Cc: Arnd Bergmann; Luis R. Rodriguez; Michael S. Tsirkin; Bjorn Helgaas; Toshi Kani; Andy Lutomirski; Juergen Gross; Tomi Valkeinen; linux-pci@...r.kernel.org; linux-kernel@...r.kernel.org; xen-devel@...ts.xensource.com; linux-fbdev; Suresh Siddha; Ingo Molnar; Thomas Gleixner; Daniel Vetter; Dave Airlie; Antonino Daplas; Jean-Christophe Plagniol-Villard; Dave Hansen; venkatesh.pallipadi@...el.com; Stefan Bader; ville.syrjala@...ux.intel.com; David Vrabel; Jan Beulich; Roger Pau Monné
Subject: Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants

On Thu, 2015-06-25 at 21:40 +0000, Casey Leedom wrote:
>
> Ah, thanks.  I see now that the __raw_*() APIs don't do any of the
> Endian Swizzling.  Unfortunately the *_relaxed() APIs on PowerPC
> are just defined as the normal *() routines.  From
> arch/powerpc/include/asm/io.h:
>
>     /*
>      * We don't do relaxed operations yet, at least not with this
> semantic
>      */

Yes so I was looking at this but there are some difficulties.
Architecturally, even with I=1 G=1 mappings (normal ioremap), we have no
guarantee of ordering of load vs. store unless I misunderstood
something. I think all current implementations provide some of that but
without barriers in the accessors, we aren't architecturally correct.

However, having those barriers will cause issues with G=0 (write
combine). It's unclear whether eieio() will provide the required
ordering for I=1 G=0 mappings and it will probably break write combine.

I'm looking into it with our HW guys and will try to come up with a
solution for power, but it doesn't help that our memory model conflates
write combining with other relaxations and that all our barriers also
prevent write combine.

Maybe we can bias the relaxed accessors toward write, by having no
barriers in it, and putting extra ones in reads.

Cheers,
Ben.

--
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/