All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haggai Eran <haggaie@mellanox.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Stephen Bates <sbates@raithlin.com>
Cc: jgunthorpe@obsidianresearch.com, sbates@raithin.com, "Raj,
	Ashok  <ashok.raj@intel.com>,
	linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	linux-rdma@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	jim.macdonald@everspin.com, linux-block@vger.kernel.org,
	Linux MM <linux-mm@kvack.org>, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory
Date: Wed, 26 Oct 2016 11:24:51 +0300	[thread overview]
Message-ID: <a5418089-2615-8c04-aca8-50ceb43978f1@mellanox.com> (raw)
In-Reply-To: <CAPcyv4gJ_c-6s2BUjsu6okR1EF53R+KNuXnOc5jv0fuwJaa3cQ@mail.gmail.com>

On 10/19/2016 6:51 AM, Dan Williams wrote:
> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sbates@raithlin.com> wrote:
>> 1. Address Translation. Suggestions have been made that in certain
>> architectures and topologies the dma_addr_t passed to the DMA master
>> in a peer-2-peer transfer will not correctly route to the IO memory
>> intended. However in our testing to date we have not seen this to be
>> an issue, even in systems with IOMMUs and PCIe switches. It is our
>> understanding that an IOMMU only maps system memory and would not
>> interfere with device memory regions.
I'm not sure that's the case. I think it works because with ZONE_DEVICE,
the iommu driver will simply treat a dma_map_page call as any other PFN,
and create a mapping as it does for any memory page.

>> (It certainly has no opportunity
>> to do so if the transfer gets routed through a switch).
It can still go through the IOMMU if you enable ACS upstream forwarding.

> There may still be platforms where peer-to-peer cycles are routed up
> through the root bridge and then back down to target device, but we
> can address that when / if it happens.
I agree.

> I wonder if we could (ab)use a
> software-defined 'pasid' as the requester id for a peer-to-peer
> mapping that needs address translation.
Why would you need that? Isn't it enough to map the peer-to-peer
addresses correctly in the iommu driver?

Haggai
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Haggai Eran <haggaie@mellanox.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Stephen Bates <sbates@raithlin.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	<linux-rdma@vger.kernel.org>, <linux-block@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	"Matthew Wilcox" <willy@linux.intel.com>,
	<jgunthorpe@obsidianresearch.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	Jens Axboe <axboe@fb.com>, Jonathan Corbet <corbet@lwn.net>,
	<jim.macdonald@everspin.com>, <sbates@raithin.com>,
	"Logan Gunthorpe" <logang@deltatee.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory
Date: Wed, 26 Oct 2016 11:24:51 +0300	[thread overview]
Message-ID: <a5418089-2615-8c04-aca8-50ceb43978f1@mellanox.com> (raw)
In-Reply-To: <CAPcyv4gJ_c-6s2BUjsu6okR1EF53R+KNuXnOc5jv0fuwJaa3cQ@mail.gmail.com>

On 10/19/2016 6:51 AM, Dan Williams wrote:
> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sbates@raithlin.com> wrote:
>> 1. Address Translation. Suggestions have been made that in certain
>> architectures and topologies the dma_addr_t passed to the DMA master
>> in a peer-2-peer transfer will not correctly route to the IO memory
>> intended. However in our testing to date we have not seen this to be
>> an issue, even in systems with IOMMUs and PCIe switches. It is our
>> understanding that an IOMMU only maps system memory and would not
>> interfere with device memory regions.
I'm not sure that's the case. I think it works because with ZONE_DEVICE,
the iommu driver will simply treat a dma_map_page call as any other PFN,
and create a mapping as it does for any memory page.

>> (It certainly has no opportunity
>> to do so if the transfer gets routed through a switch).
It can still go through the IOMMU if you enable ACS upstream forwarding.

> There may still be platforms where peer-to-peer cycles are routed up
> through the root bridge and then back down to target device, but we
> can address that when / if it happens.
I agree.

> I wonder if we could (ab)use a
> software-defined 'pasid' as the requester id for a peer-to-peer
> mapping that needs address translation.
Why would you need that? Isn't it enough to map the peer-to-peer
addresses correctly in the iommu driver?

Haggai

WARNING: multiple messages have this Message-ID (diff)
From: Haggai Eran <haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
To: Dan Williams
	<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Stephen Bates <sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org>
Cc: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org,
	sbates-Rgftl6RXld5BDgjK7y7TUQ@public.gmane.org, "Raj,
	Ashok" <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
	<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	jim.macdonald-FgSLVYC75IpWk0Htik3J/w@public.gmane.org,
	linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Jens Axboe <axboe-b10kYP2dOMg@public.gmane.org>,
	Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory
Date: Wed, 26 Oct 2016 11:24:51 +0300	[thread overview]
Message-ID: <a5418089-2615-8c04-aca8-50ceb43978f1@mellanox.com> (raw)
In-Reply-To: <CAPcyv4gJ_c-6s2BUjsu6okR1EF53R+KNuXnOc5jv0fuwJaa3cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 10/19/2016 6:51 AM, Dan Williams wrote:
> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org> wrote:
>> 1. Address Translation. Suggestions have been made that in certain
>> architectures and topologies the dma_addr_t passed to the DMA master
>> in a peer-2-peer transfer will not correctly route to the IO memory
>> intended. However in our testing to date we have not seen this to be
>> an issue, even in systems with IOMMUs and PCIe switches. It is our
>> understanding that an IOMMU only maps system memory and would not
>> interfere with device memory regions.
I'm not sure that's the case. I think it works because with ZONE_DEVICE,
the iommu driver will simply treat a dma_map_page call as any other PFN,
and create a mapping as it does for any memory page.

>> (It certainly has no opportunity
>> to do so if the transfer gets routed through a switch).
It can still go through the IOMMU if you enable ACS upstream forwarding.

> There may still be platforms where peer-to-peer cycles are routed up
> through the root bridge and then back down to target device, but we
> can address that when / if it happens.
I agree.

> I wonder if we could (ab)use a
> software-defined 'pasid' as the requester id for a peer-to-peer
> mapping that needs address translation.
Why would you need that? Isn't it enough to map the peer-to-peer
addresses correctly in the iommu driver?

Haggai

WARNING: multiple messages have this Message-ID (diff)
From: Haggai Eran <haggaie@mellanox.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Stephen Bates <sbates@raithlin.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	<linux-rdma@vger.kernel.org>, <linux-block@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	"Matthew Wilcox" <willy@linux.intel.com>,
	<jgunthorpe@obsidianresearch.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	Jens Axboe <axboe@fb.com>, Jonathan Corbet <corbet@lwn.net>,
	<jim.macdonald@everspin.com>, <sbates@raithin.com>,
	"Logan Gunthorpe" <logang@deltatee.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory
Date: Wed, 26 Oct 2016 11:24:51 +0300	[thread overview]
Message-ID: <a5418089-2615-8c04-aca8-50ceb43978f1@mellanox.com> (raw)
In-Reply-To: <CAPcyv4gJ_c-6s2BUjsu6okR1EF53R+KNuXnOc5jv0fuwJaa3cQ@mail.gmail.com>

On 10/19/2016 6:51 AM, Dan Williams wrote:
> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sbates@raithlin.com> wrote:
>> 1. Address Translation. Suggestions have been made that in certain
>> architectures and topologies the dma_addr_t passed to the DMA master
>> in a peer-2-peer transfer will not correctly route to the IO memory
>> intended. However in our testing to date we have not seen this to be
>> an issue, even in systems with IOMMUs and PCIe switches. It is our
>> understanding that an IOMMU only maps system memory and would not
>> interfere with device memory regions.
I'm not sure that's the case. I think it works because with ZONE_DEVICE,
the iommu driver will simply treat a dma_map_page call as any other PFN,
and create a mapping as it does for any memory page.

>> (It certainly has no opportunity
>> to do so if the transfer gets routed through a switch).
It can still go through the IOMMU if you enable ACS upstream forwarding.

> There may still be platforms where peer-to-peer cycles are routed up
> through the root bridge and then back down to target device, but we
> can address that when / if it happens.
I agree.

> I wonder if we could (ab)use a
> software-defined 'pasid' as the requester id for a peer-to-peer
> mapping that needs address translation.
Why would you need that? Isn't it enough to map the peer-to-peer
addresses correctly in the iommu driver?

Haggai

WARNING: multiple messages have this Message-ID (diff)
From: Haggai Eran <haggaie@mellanox.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Stephen Bates <sbates@raithlin.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	linux-rdma@vger.kernel.org, linux-block@vger.kernel.org,
	Linux MM <linux-mm@kvack.org>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	jgunthorpe@obsidianresearch.com,
	Christoph Hellwig <hch@infradead.org>, Jens Axboe <axboe@fb.com>,
	Jonathan Corbet <corbet@lwn.net>,
	jim.macdonald@everspin.com, sbates@raithin.com,
	Logan Gunthorpe <logang@deltatee.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory
Date: Wed, 26 Oct 2016 11:24:51 +0300	[thread overview]
Message-ID: <a5418089-2615-8c04-aca8-50ceb43978f1@mellanox.com> (raw)
In-Reply-To: <CAPcyv4gJ_c-6s2BUjsu6okR1EF53R+KNuXnOc5jv0fuwJaa3cQ@mail.gmail.com>

On 10/19/2016 6:51 AM, Dan Williams wrote:
> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sbates@raithlin.com> wrote:
>> 1. Address Translation. Suggestions have been made that in certain
>> architectures and topologies the dma_addr_t passed to the DMA master
>> in a peer-2-peer transfer will not correctly route to the IO memory
>> intended. However in our testing to date we have not seen this to be
>> an issue, even in systems with IOMMUs and PCIe switches. It is our
>> understanding that an IOMMU only maps system memory and would not
>> interfere with device memory regions.
I'm not sure that's the case. I think it works because with ZONE_DEVICE,
the iommu driver will simply treat a dma_map_page call as any other PFN,
and create a mapping as it does for any memory page.

>> (It certainly has no opportunity
>> to do so if the transfer gets routed through a switch).
It can still go through the IOMMU if you enable ACS upstream forwarding.

> There may still be platforms where peer-to-peer cycles are routed up
> through the root bridge and then back down to target device, but we
> can address that when / if it happens.
I agree.

> I wonder if we could (ab)use a
> software-defined 'pasid' as the requester id for a peer-to-peer
> mapping that needs address translation.
Why would you need that? Isn't it enough to map the peer-to-peer
addresses correctly in the iommu driver?

Haggai

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2016-10-26  8:25 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-18 21:42 [PATCH 0/3] iopmem : A block device for PCIe memory Stephen Bates
2016-10-18 21:42 ` Stephen Bates
2016-10-18 21:42 ` Stephen Bates
2016-10-18 21:42 ` Stephen Bates
2016-10-18 21:42 ` Stephen Bates
2016-10-18 21:42 ` [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-19 17:50   ` Dan Williams
2016-10-19 17:50     ` Dan Williams
2016-10-19 17:50     ` Dan Williams
2016-10-19 17:50     ` Dan Williams
2016-10-19 17:50     ` Dan Williams
2016-10-19 18:40     ` Stephen Bates
2016-10-19 18:40       ` Stephen Bates
2016-10-19 18:40       ` Stephen Bates
2016-10-19 20:01       ` Dan Williams
2016-10-19 20:01         ` Dan Williams
2016-10-19 20:01         ` Dan Williams
2016-10-19 20:01         ` Dan Williams
2016-10-19 20:01         ` Dan Williams
2016-10-25 11:54         ` Stephen Bates
2016-10-25 11:54           ` Stephen Bates
2016-10-25 11:54           ` Stephen Bates
2016-10-25 11:54           ` Stephen Bates
2016-10-18 21:42 ` [PATCH 2/3] iopmem : Add a block device driver for PCIe attached IO memory Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-18 21:42   ` Stephen Bates
     [not found]   ` <1476826937-20665-3-git-send-email-sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org>
2016-10-28  6:45     ` Christoph Hellwig
2016-10-28  6:45       ` Christoph Hellwig
2016-10-28  6:45       ` Christoph Hellwig
     [not found]       ` <20161028064556.GA3231-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-10-28 19:22         ` Logan Gunthorpe
2016-10-28 19:22           ` Logan Gunthorpe
2016-10-28 19:22           ` Logan Gunthorpe
2016-10-18 21:42 ` [PATCH 3/3] iopmem : Add documentation for iopmem driver Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-18 21:42   ` Stephen Bates
2016-10-18 21:42   ` Stephen Bates
     [not found]   ` <1476826937-20665-4-git-send-email-sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org>
2016-10-28  6:46     ` Christoph Hellwig
2016-10-28  6:46       ` Christoph Hellwig
2016-10-28  6:46       ` Christoph Hellwig
2016-10-19  3:51 ` [PATCH 0/3] iopmem : A block device for PCIe memory Dan Williams
2016-10-19  3:51   ` Dan Williams
2016-10-19  3:51   ` Dan Williams
2016-10-19  3:51   ` Dan Williams
2016-10-19 18:48   ` Stephen Bates
2016-10-19 18:48     ` Stephen Bates
2016-10-19 18:48     ` Stephen Bates
2016-10-19 18:48     ` Stephen Bates
2016-10-19 19:58     ` Dan Williams
2016-10-19 19:58       ` Dan Williams
2016-10-19 19:58       ` Dan Williams
2016-10-19 19:58       ` Dan Williams
2016-10-19 22:54       ` Stephen Bates
2016-10-19 22:54         ` Stephen Bates
2016-10-19 22:54         ` Stephen Bates
2016-10-19 22:54         ` Stephen Bates
2016-10-20 23:22     ` Dave Chinner
2016-10-20 23:22       ` Dave Chinner
2016-10-20 23:22       ` Dave Chinner
2016-10-20 23:22       ` Dave Chinner
2016-10-21  9:57       ` Christoph Hellwig
2016-10-21  9:57         ` Christoph Hellwig
2016-10-21  9:57         ` Christoph Hellwig
2016-10-21 11:12         ` Dave Chinner
2016-10-21 11:12           ` Dave Chinner
2016-10-21 11:12           ` Dave Chinner
2016-10-25 11:50           ` Stephen Bates
2016-10-25 11:50             ` Stephen Bates
2016-10-25 11:50             ` Stephen Bates
2016-10-25 21:19             ` Dave Chinner
2016-10-25 21:19               ` Dave Chinner
2016-10-25 21:19               ` Dave Chinner
2016-11-06 14:05               ` Stephen Bates
2016-11-06 14:05                 ` Stephen Bates
2016-11-06 14:05                 ` Stephen Bates
2016-11-06 14:05                 ` Stephen Bates
2016-10-27 10:22         ` Sagi Grimberg
2016-10-27 10:22           ` Sagi Grimberg
2016-10-27 10:22           ` Sagi Grimberg
2016-10-27 12:32           ` Christoph Hellwig
2016-10-27 12:32             ` Christoph Hellwig
2016-10-27 12:32             ` Christoph Hellwig
2016-10-27 12:32             ` Christoph Hellwig
2016-10-26  8:24   ` Haggai Eran [this message]
2016-10-26  8:24     ` Haggai Eran
2016-10-26  8:24     ` Haggai Eran
2016-10-26  8:24     ` Haggai Eran
2016-10-26  8:24     ` Haggai Eran
2016-10-26 13:39     ` Dan Williams
2016-10-26 13:39       ` Dan Williams
2016-10-26 13:39       ` Dan Williams
2016-10-26 13:39       ` Dan Williams
2016-10-26 13:39       ` Dan Williams

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=a5418089-2615-8c04-aca8-50ceb43978f1@mellanox.com \
    --to=haggaie@mellanox.com \
    --cc=axboe@fb.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=hch@infradead.org \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=jim.macdonald@everspin.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sbates@raithin.com \
    --cc=sbates@raithlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.