linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christoph Hellwig <hch@lst.de>
Cc: torvalds@linux-foundation.org, axboe@kernel.dk,
	dan.j.williams@intel.com,  vgupta@synopsys.com,
	hskinnemoen@gmail.com, egtvedt@samfundet.no,  realmz6@gmail.com,
	dhowells@redhat.com, monstr@monstr.eu, x86@kernel.org,
	 dwmw2@infradead.org, alex.williamson@redhat.com,
	grundler@parisc-linux.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org,
	linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org,
	linux-mips@linux-mips.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-nvdimm@ml01.01.org, linux-media@vger.kernel.org
Subject: Re: RFC: prepare for struct scatterlist entries without page backing
Date: Wed, 12 Aug 2015 10:00:07 -0700	[thread overview]
Message-ID: <1439398807.2825.51.camel@HansenPartnership.com> (raw)
In-Reply-To: <1439363150-8661-1-git-send-email-hch@lst.de>

On Wed, 2015-08-12 at 09:05 +0200, Christoph Hellwig wrote:
> Dan Williams started to look into addressing I/O to and from
> Persistent Memory in his series from June:
> 
> 	http://thread.gmane.org/gmane.linux.kernel.cross-arch/27944
> 
> I've started looking into DMA mapping of these SGLs specifically instead
> of the map_pfn method in there.  In addition to supporting NVDIMM backed
> I/O I also suspect this would be highly useful for media drivers that
> go through nasty hoops to be able to DMA from/to their ioremapped regions,
> with vb2_dc_get_userptr in drivers/media/v4l2-core/videobuf2-dma-contig.c
> being a prime example for the unsafe hacks currently used.
> 
> It turns out most DMA mapping implementation can handle SGLs without
> page structures with some fairly simple mechanical work.  Most of it
> is just about consistently using sg_phys.  For implementations that
> need to flush caches we need a new helper that skips these cache
> flushes if a entry doesn't have a kernel virtual address.
> 
> However the ccio (parisc) and sba_iommu (parisc & ia64) IOMMUs seem
> to be operate mostly on virtual addresses.  It's a fairly odd concept
> that I don't fully grasp, so I'll need some help with those if we want
> to bring this forward.

I can explain that.  I think this doesn't apply to ia64 because it's
cache is PIPT, but on parisc, we have a VIPT cache.

On normal physically indexed architectures, when the iommu sees a DMA
transfer to/from physical memory, it also notifies the CPU to flush the
internal CPU caches of those lines.  This is usually an interlocking
step of the transfer to make sure the page is coherent before transfer
to/from the device (it's why the ia32 for instance is a coherent
architecture).  Because the system is physically indexed, there's no
need to worry about aliases.

On Virtually Indexed systems, like parisc, there is an aliasing problem.
The CCIO iommu unit (and all other iommu systems on parisc) have what's
called a local coherence index (LCI).  You program it as part of the
IOMMU page table and it tells the system which Virtual line in the cache
to flush as part of the IO transaction, thus still ensuring cache
coherence.  That's why we have to know the virtual as well as physical
addresses for the page.  The problem we have in Linux is that we have
two virtual addresses, which are often incoherent aliases: the user
virtual address and a kernel virtual address but we can only make the
page coherent with a single alias (only one LCI).  The way I/O on Linux
currently works is that get_user_pages actually flushes the user virtual
address, so that's expected to be coherent, so the address we program
into the VCI is the kernel virtual address.  Usually nothing in the
kernel has ever touched the page, so there's nothing to flush, but we do
it just in case.

In theory, for these non kernel page backed SG entries, we can make the
process more efficient by not flushing in gup and instead programming
the user virtual address into the local coherence index.  However,
simply zeroing the LCI will also work (except that poor VI zero line
will get flushed repeatedly, so it's probably best to pick a known
untouched line in the kernel).

James

  parent reply	other threads:[~2015-08-12 17:08 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-12  7:05 RFC: prepare for struct scatterlist entries without page backing Christoph Hellwig
2015-08-12  7:05 ` [PATCH 01/31] scatterlist: add sg_pfn and sg_has_page helpers Christoph Hellwig
2015-08-12  7:05 ` [PATCH 02/31] scatterlist: use sg_phys() Christoph Hellwig
2015-08-12  7:05 ` [PATCH 03/31] dma-debug: handle page-less SG entries Christoph Hellwig
2015-08-12  7:05 ` [PATCH 04/31] x86/pci-nommu: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 05/31] x86/pci-calgary: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 06/31] alpha/pci-noop: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 07/31] alpha/pci_iommu: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 08/31] c6x: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 09/31] ia64/pci_dma: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 10/31] powerpc/iommu: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 11/31] sparc/iommu: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 12/31] mn10300: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 13/31] sparc/ldc: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 14/31] sparc32/io-unit: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 15/31] sparc32/iommu: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 16/31] s390: " Christoph Hellwig
2015-08-12 11:51   ` Sebastian Ott
2015-08-12  7:05 ` [PATCH 17/31] ia64/sba_iommu: remove sba_sg_address Christoph Hellwig
2015-08-12  7:05 ` [PATCH 18/31] nios2: handle page-less SG entries Christoph Hellwig
2015-08-12  7:05 ` [PATCH 19/31] arc: " Christoph Hellwig
2015-08-12 10:28   ` Vineet Gupta
2015-08-12  7:05 ` [PATCH 20/31] avr32: " Christoph Hellwig
2015-08-12  9:36   ` Hans-Christian Egtvedt
2015-08-12  7:05 ` [PATCH 21/31] blackfin: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 22/31] metag: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 23/31] sh: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 24/31] xtensa: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 25/31] frv: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 26/31] openrisc: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 27/31] mips: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 28/31] powerpc: " Christoph Hellwig
2015-08-12  7:05 ` [PATCH 29/31] parisc: " Christoph Hellwig
2015-08-12 16:01   ` Linus Torvalds
2015-08-13 14:31     ` Christoph Hellwig
2015-08-14  3:30       ` Dan Williams
2015-08-14  3:59         ` James Bottomley
2015-08-14  4:11           ` David Miller
2015-08-14 16:17             ` Dan Williams
2015-08-12  7:05 ` [PATCH 30/31] intel-iommu: " Christoph Hellwig
2015-08-12  9:51   ` David Woodhouse
2015-08-12  7:05 ` [PATCH 31/31] dma-mapping-common: skip kmemleak checks for " Christoph Hellwig
2015-08-12 16:05   ` Linus Torvalds
2015-08-13 14:33     ` Christoph Hellwig
2015-08-12 16:26   ` Catalin Marinas
2015-08-12 12:42 ` RFC: prepare for struct scatterlist entries without page backing Boaz Harrosh
2015-08-12 23:37   ` Julian Calaby
2015-08-13 14:35     ` Christoph Hellwig
2015-08-13 23:40       ` Julian Calaby
2015-08-13 14:40   ` Christoph Hellwig
2015-08-13 15:42     ` Boaz Harrosh
2015-08-12 17:00 ` James Bottomley [this message]
2015-08-12 17:56   ` Grant Grundler

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=1439398807.2825.51.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=alex.williamson@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=egtvedt@samfundet.no \
    --cc=grundler@parisc-linux.org \
    --cc=hch@lst.de \
    --cc=hskinnemoen@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=monstr@monstr.eu \
    --cc=realmz6@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vgupta@synopsys.com \
    --cc=x86@kernel.org \
    /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).