[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()

On Fri, Jun 26, 2015 at 12:12:06PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2015-06-24 at 18:22 -0700, Luis R. Rodriguez wrote:
> > Although I had test compiled this before just to be safe I went ahead and
> > successfully test-compiled this set with allmodconfig, specially since I've 
> > now
> > removed the exports for the devres routines.  Please let me know if these 
> > might
> > be able to go through you or if there are any questions. I will note the 
> > recent
> > discussion with Benjamin over the v7 series concluded that the ideas we both
> > were alluding to, on automating instead the WC effects for devices seems a 
> > bit
> > too idealistic for PCI / PCIE for now, but perhaps we should at least 
> > consider
> > this in the future for userspace mmap() calls [4].
> So I've been trying to figure out how to make this practically work for us 
> (powerpc).
> writel() will never write combine for us, it uses too heavy barriers.
> writel_relaxed() today is identical to writel() but we can change it.
> The problem is that switching to G=0 mappings (which is what provides us with 
> write
> combining) also architecturally enables prefetch and speculative loads... and 
> again
> architecturally (the implementations may differ), kills the effect of the 
> lightweight
> io barrier eieio which we would have to use in readl_relaxed() and 
> writel_relaxed()
> to provide their normal semantics.
> So it boils down to: Can we modify the documentation of readl_relaxed() and 
> writel_relaxed()
> to define them as being even further relaxed when using a "wc" mapping ?
> Otherwise, the only way out I see for us on powerpc is to bias massively 
> writel_relaxed()
> against real_relaxed() by putting heavy barriers around the load in the 
> latter so we can
> keep them completely out of the former and still enable wc.

Depends if you semantically then also are implicating its use for the 
area and if we've ensured we've visited all other possibilities to avoid this. 
of replying here though it seems we have a large general ioremap() semantic 
ongoing on another thread which is far ahead of this one and more generalized. 
following up there, seems the party is there:



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.