All of lore.kernel.org
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: Robin Murphy <robin.murphy@arm.com>,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	linux-block@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org
Cc: "Minturn Dave B" <dave.b.minturn@intel.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Ira Weiny" <iweiny@intel.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jason Ekstrand" <jason@jlekstrand.net>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Stephen Bates" <sbates@raithlin.com>,
	"Jakowski Andrzej" <andrzej.jakowski@intel.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Xiong Jianxin" <jianxin.xiong@intel.com>
Subject: Re: [RFC PATCH v2 08/11] iommu/dma: Support PCI P2PDMA pages in dma-iommu map_sg
Date: Fri, 12 Mar 2021 13:06:34 -0700	[thread overview]
Message-ID: <6dd679b3-e38b-2c18-1990-bfc96bb4d971@deltatee.com> (raw)
In-Reply-To: <76cc1c82-3cf4-92d3-992f-5c876ed30523@arm.com>



On 2021-03-12 12:47 p.m., Robin Murphy wrote:
>>>>    {
>>>>        struct scatterlist *s, *cur = sg;
>>>>        unsigned long seg_mask = dma_get_seg_boundary(dev);
>>>> @@ -864,6 +865,20 @@ static int __finalise_sg(struct device *dev,
>>>> struct scatterlist *sg, int nents,
>>>>            sg_dma_address(s) = DMA_MAPPING_ERROR;
>>>>            sg_dma_len(s) = 0;
>>>>    +        if (is_pci_p2pdma_page(sg_page(s)) && !s_iova_len) {
>>>> +            if (i > 0)
>>>> +                cur = sg_next(cur);
>>>> +
>>>> +            sg_dma_address(cur) = sg_phys(s) + s->offset -
>>>
>>> Are you sure about that? ;)
>>
>> Do you see a bug? I don't follow you...
> 
> sg_phys() already accounts for the offset, so you're adding it twice.

Ah, oops. Nice catch. I missed that.

> 
>>>> +                pci_p2pdma_bus_offset(sg_page(s));
>>>
>>> Can the bus offset make P2P addresses overlap with regions of mem space
>>> that we might use for regular IOVA allocation? That would be very bad...
>>
>> No. IOMMU drivers already disallow all PCI addresses from being used as
>> IOVA addresses. See, for example,  dmar_init_reserved_ranges(). It would
>> be a huge problem for a whole lot of other reasons if it didn't.
> 
> I know we reserve the outbound windows (largely *because* some host 
> bridges will consider those addresses as attempts at unsupported P2P and 
> prevent them working), I just wanted to confirm that this bus offset is 
> always something small that stays within the relevant window, rather 
> than something that might make a BAR appear in a completely different 
> place for P2P purposes. If so, that's good.

Yes, well if an IOVA overlaps with any PCI bus address there's going to 
be some difficult brokenness because when the IOVA is used it might be 
directed to the a PCI device and not the IOMMU. I fixed a bug like that 
once.
>>> I'm not really thrilled about the idea of passing zero-length segments
>>> to iommu_map_sg(). Yes, it happens to trick the concatenation logic in
>>> the current implementation into doing what you want, but it feels 
>>> fragile.
>>
>> We're not passing zero length segments to iommu_map_sg() (or any
>> function). This loop is just scanning to calculate the length of the
>> required IOVA. __finalise_sg() (which is intimately tied to this loop)
>> then needs a way to determine which segments were P2P segments. The
>> existing code already overwrites s->length with an aligned length and
>> stores the original length in sg_dma_len. So we're not relying on
>> tricking any logic here.
> 
> Yes, we temporarily shuffle in page-aligned quantities to satisfy the 
> needs of the iommu_map_sg() call, before unpacking things again in 
> __finalise_sg(). It's some disgusting trickery that I'm particularly 
> proud of. My point is that if you have a mix of both p2p and normal 
> segments - which seems to be a case you want to support - then the 
> length of 0 that you set to flag p2p segments here will be seen by 
> iommu_map_sg() (as it walks the list to map the other segments) before 
> you then use it as a key to override the DMA address in the final step. 
> It's not a concern if you have a p2p-only list and short-circuit 
> straight to that step (in which case all the shuffling was wasted effort 
> anyway), but since it's not entirely clear what a segment with zero 
> length would mean in general, it seems like a good idea to avoid passing 
> the list across a public boundary in that state, if possible.

Ok, well, I mean the iommu_map_sg() does the right thing as is without 
changing it and IMO sg->length set to zero does make sense. Supporting 
mixed P2P and normal segments is really the whole point of this series 
(the current kernel supports homogeneous SGLs with a specialized path -- 
see pci_p2pdma_unmap_sg_attrs()). But do you have an alternate solution 
for sg->length?

Logan

WARNING: multiple messages have this Message-ID (diff)
From: Logan Gunthorpe <logang@deltatee.com>
To: Robin Murphy <robin.murphy@arm.com>,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	linux-block@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org
Cc: "Minturn Dave B" <dave.b.minturn@intel.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Ira Weiny" <iweiny@intel.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jason Ekstrand" <jason@jlekstrand.net>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Stephen Bates" <sbates@raithlin.com>,
	"Jakowski Andrzej" <andrzej.jakowski@intel.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Xiong Jianxin" <jianxin.xiong@intel.com>
Subject: Re: [RFC PATCH v2 08/11] iommu/dma: Support PCI P2PDMA pages in dma-iommu map_sg
Date: Fri, 12 Mar 2021 13:06:34 -0700	[thread overview]
Message-ID: <6dd679b3-e38b-2c18-1990-bfc96bb4d971@deltatee.com> (raw)
In-Reply-To: <76cc1c82-3cf4-92d3-992f-5c876ed30523@arm.com>



On 2021-03-12 12:47 p.m., Robin Murphy wrote:
>>>>    {
>>>>        struct scatterlist *s, *cur = sg;
>>>>        unsigned long seg_mask = dma_get_seg_boundary(dev);
>>>> @@ -864,6 +865,20 @@ static int __finalise_sg(struct device *dev,
>>>> struct scatterlist *sg, int nents,
>>>>            sg_dma_address(s) = DMA_MAPPING_ERROR;
>>>>            sg_dma_len(s) = 0;
>>>>    +        if (is_pci_p2pdma_page(sg_page(s)) && !s_iova_len) {
>>>> +            if (i > 0)
>>>> +                cur = sg_next(cur);
>>>> +
>>>> +            sg_dma_address(cur) = sg_phys(s) + s->offset -
>>>
>>> Are you sure about that? ;)
>>
>> Do you see a bug? I don't follow you...
> 
> sg_phys() already accounts for the offset, so you're adding it twice.

Ah, oops. Nice catch. I missed that.

> 
>>>> +                pci_p2pdma_bus_offset(sg_page(s));
>>>
>>> Can the bus offset make P2P addresses overlap with regions of mem space
>>> that we might use for regular IOVA allocation? That would be very bad...
>>
>> No. IOMMU drivers already disallow all PCI addresses from being used as
>> IOVA addresses. See, for example,  dmar_init_reserved_ranges(). It would
>> be a huge problem for a whole lot of other reasons if it didn't.
> 
> I know we reserve the outbound windows (largely *because* some host 
> bridges will consider those addresses as attempts at unsupported P2P and 
> prevent them working), I just wanted to confirm that this bus offset is 
> always something small that stays within the relevant window, rather 
> than something that might make a BAR appear in a completely different 
> place for P2P purposes. If so, that's good.

Yes, well if an IOVA overlaps with any PCI bus address there's going to 
be some difficult brokenness because when the IOVA is used it might be 
directed to the a PCI device and not the IOMMU. I fixed a bug like that 
once.
>>> I'm not really thrilled about the idea of passing zero-length segments
>>> to iommu_map_sg(). Yes, it happens to trick the concatenation logic in
>>> the current implementation into doing what you want, but it feels 
>>> fragile.
>>
>> We're not passing zero length segments to iommu_map_sg() (or any
>> function). This loop is just scanning to calculate the length of the
>> required IOVA. __finalise_sg() (which is intimately tied to this loop)
>> then needs a way to determine which segments were P2P segments. The
>> existing code already overwrites s->length with an aligned length and
>> stores the original length in sg_dma_len. So we're not relying on
>> tricking any logic here.
> 
> Yes, we temporarily shuffle in page-aligned quantities to satisfy the 
> needs of the iommu_map_sg() call, before unpacking things again in 
> __finalise_sg(). It's some disgusting trickery that I'm particularly 
> proud of. My point is that if you have a mix of both p2p and normal 
> segments - which seems to be a case you want to support - then the 
> length of 0 that you set to flag p2p segments here will be seen by 
> iommu_map_sg() (as it walks the list to map the other segments) before 
> you then use it as a key to override the DMA address in the final step. 
> It's not a concern if you have a p2p-only list and short-circuit 
> straight to that step (in which case all the shuffling was wasted effort 
> anyway), but since it's not entirely clear what a segment with zero 
> length would mean in general, it seems like a good idea to avoid passing 
> the list across a public boundary in that state, if possible.

Ok, well, I mean the iommu_map_sg() does the right thing as is without 
changing it and IMO sg->length set to zero does make sense. Supporting 
mixed P2P and normal segments is really the whole point of this series 
(the current kernel supports homogeneous SGLs with a specialized path -- 
see pci_p2pdma_unmap_sg_attrs()). But do you have an alternate solution 
for sg->length?

Logan

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

WARNING: multiple messages have this Message-ID (diff)
From: Logan Gunthorpe <logang@deltatee.com>
To: Robin Murphy <robin.murphy@arm.com>,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	linux-block@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org
Cc: "Minturn Dave B" <dave.b.minturn@intel.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Ira Weiny" <iweiny@intel.com>, "Christoph Hellwig" <hch@lst.de>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Stephen Bates" <sbates@raithlin.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jason Ekstrand" <jason@jlekstrand.net>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Jakowski Andrzej" <andrzej.jakowski@intel.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Xiong Jianxin" <jianxin.xiong@intel.com>
Subject: Re: [RFC PATCH v2 08/11] iommu/dma: Support PCI P2PDMA pages in dma-iommu map_sg
Date: Fri, 12 Mar 2021 13:06:34 -0700	[thread overview]
Message-ID: <6dd679b3-e38b-2c18-1990-bfc96bb4d971@deltatee.com> (raw)
In-Reply-To: <76cc1c82-3cf4-92d3-992f-5c876ed30523@arm.com>



On 2021-03-12 12:47 p.m., Robin Murphy wrote:
>>>>    {
>>>>        struct scatterlist *s, *cur = sg;
>>>>        unsigned long seg_mask = dma_get_seg_boundary(dev);
>>>> @@ -864,6 +865,20 @@ static int __finalise_sg(struct device *dev,
>>>> struct scatterlist *sg, int nents,
>>>>            sg_dma_address(s) = DMA_MAPPING_ERROR;
>>>>            sg_dma_len(s) = 0;
>>>>    +        if (is_pci_p2pdma_page(sg_page(s)) && !s_iova_len) {
>>>> +            if (i > 0)
>>>> +                cur = sg_next(cur);
>>>> +
>>>> +            sg_dma_address(cur) = sg_phys(s) + s->offset -
>>>
>>> Are you sure about that? ;)
>>
>> Do you see a bug? I don't follow you...
> 
> sg_phys() already accounts for the offset, so you're adding it twice.

Ah, oops. Nice catch. I missed that.

> 
>>>> +                pci_p2pdma_bus_offset(sg_page(s));
>>>
>>> Can the bus offset make P2P addresses overlap with regions of mem space
>>> that we might use for regular IOVA allocation? That would be very bad...
>>
>> No. IOMMU drivers already disallow all PCI addresses from being used as
>> IOVA addresses. See, for example,  dmar_init_reserved_ranges(). It would
>> be a huge problem for a whole lot of other reasons if it didn't.
> 
> I know we reserve the outbound windows (largely *because* some host 
> bridges will consider those addresses as attempts at unsupported P2P and 
> prevent them working), I just wanted to confirm that this bus offset is 
> always something small that stays within the relevant window, rather 
> than something that might make a BAR appear in a completely different 
> place for P2P purposes. If so, that's good.

Yes, well if an IOVA overlaps with any PCI bus address there's going to 
be some difficult brokenness because when the IOVA is used it might be 
directed to the a PCI device and not the IOMMU. I fixed a bug like that 
once.
>>> I'm not really thrilled about the idea of passing zero-length segments
>>> to iommu_map_sg(). Yes, it happens to trick the concatenation logic in
>>> the current implementation into doing what you want, but it feels 
>>> fragile.
>>
>> We're not passing zero length segments to iommu_map_sg() (or any
>> function). This loop is just scanning to calculate the length of the
>> required IOVA. __finalise_sg() (which is intimately tied to this loop)
>> then needs a way to determine which segments were P2P segments. The
>> existing code already overwrites s->length with an aligned length and
>> stores the original length in sg_dma_len. So we're not relying on
>> tricking any logic here.
> 
> Yes, we temporarily shuffle in page-aligned quantities to satisfy the 
> needs of the iommu_map_sg() call, before unpacking things again in 
> __finalise_sg(). It's some disgusting trickery that I'm particularly 
> proud of. My point is that if you have a mix of both p2p and normal 
> segments - which seems to be a case you want to support - then the 
> length of 0 that you set to flag p2p segments here will be seen by 
> iommu_map_sg() (as it walks the list to map the other segments) before 
> you then use it as a key to override the DMA address in the final step. 
> It's not a concern if you have a p2p-only list and short-circuit 
> straight to that step (in which case all the shuffling was wasted effort 
> anyway), but since it's not entirely clear what a segment with zero 
> length would mean in general, it seems like a good idea to avoid passing 
> the list across a public boundary in that state, if possible.

Ok, well, I mean the iommu_map_sg() does the right thing as is without 
changing it and IMO sg->length set to zero does make sense. Supporting 
mixed P2P and normal segments is really the whole point of this series 
(the current kernel supports homogeneous SGLs with a specialized path -- 
see pci_p2pdma_unmap_sg_attrs()). But do you have an alternate solution 
for sg->length?

Logan
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-03-12 20:07 UTC|newest]

Thread overview: 141+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 23:31 [RFC PATCH v2 00/11] Add support to dma_map_sg for P2PDMA Logan Gunthorpe
2021-03-11 23:31 ` Logan Gunthorpe
2021-03-11 23:31 ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 01/11] PCI/P2PDMA: Pass gfp_mask flags to upstream_bridge_distance_warn() Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-12 20:39   ` Bjorn Helgaas
2021-03-12 20:39     ` Bjorn Helgaas
2021-03-12 20:39     ` Bjorn Helgaas
2021-03-12 20:53     ` Logan Gunthorpe
2021-03-12 20:53       ` Logan Gunthorpe
2021-03-12 20:53       ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 02/11] PCI/P2PDMA: Avoid pci_get_slot() which sleeps Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-12 20:57   ` Bjorn Helgaas
2021-03-12 20:57     ` Bjorn Helgaas
2021-03-12 20:57     ` Bjorn Helgaas
2021-03-12 21:37     ` Logan Gunthorpe
2021-03-12 21:37       ` Logan Gunthorpe
2021-03-12 21:37       ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 03/11] PCI/P2PDMA: Attempt to set map_type if it has not been set Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 04/11] PCI/P2PDMA: Introduce pci_p2pdma_should_map_bus() and pci_p2pdma_bus_offset() Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-13  1:38   ` Ira Weiny
2021-03-13  1:38     ` Ira Weiny
2021-03-13  1:38     ` Ira Weiny
2021-03-15 16:27     ` Logan Gunthorpe
2021-03-15 16:27       ` Logan Gunthorpe
2021-03-15 16:27       ` Logan Gunthorpe
2021-03-24 17:21       ` Jason Gunthorpe
2021-03-24 17:21         ` Jason Gunthorpe
2021-03-24 17:21         ` Jason Gunthorpe
2021-03-24 18:34         ` Christian König
2021-03-24 18:34           ` Christian König
2021-03-24 18:34           ` Christian König
2021-03-13  2:32   ` Ira Weiny
2021-03-13  2:32     ` Ira Weiny
2021-03-13  2:32     ` Ira Weiny
2021-03-15 16:30     ` Logan Gunthorpe
2021-03-15 16:30       ` Logan Gunthorpe
2021-03-15 16:30       ` Logan Gunthorpe
2021-03-16  8:14   ` Christoph Hellwig
2021-03-16  8:14     ` Christoph Hellwig
2021-03-16  8:14     ` Christoph Hellwig
2021-03-11 23:31 ` [RFC PATCH v2 05/11] lib/scatterlist: Add flag for indicating P2PDMA segments in an SGL Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 06/11] dma-direct: Support PCI P2PDMA pages in dma-direct map_sg Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-12 15:52   ` Robin Murphy
2021-03-12 15:52     ` Robin Murphy
2021-03-12 15:52     ` Robin Murphy
2021-03-12 16:24     ` Logan Gunthorpe
2021-03-12 16:24       ` Logan Gunthorpe
2021-03-12 16:24       ` Logan Gunthorpe
2021-03-12 18:11       ` Robin Murphy
2021-03-12 18:11         ` Robin Murphy
2021-03-12 18:11         ` Robin Murphy
2021-03-12 18:27         ` Logan Gunthorpe
2021-03-12 18:27           ` Logan Gunthorpe
2021-03-12 18:27           ` Logan Gunthorpe
2021-03-16  7:58           ` Christoph Hellwig
2021-03-16  7:58             ` Christoph Hellwig
2021-03-16  7:58             ` Christoph Hellwig
2021-03-16 15:54             ` Logan Gunthorpe
2021-03-16 15:54               ` Logan Gunthorpe
2021-03-16 15:54               ` Logan Gunthorpe
2021-03-16  7:56         ` Christoph Hellwig
2021-03-16  7:56           ` Christoph Hellwig
2021-03-16  7:56           ` Christoph Hellwig
2021-03-16  8:11   ` Christoph Hellwig
2021-03-16  8:11     ` Christoph Hellwig
2021-03-16  8:11     ` Christoph Hellwig
2021-03-11 23:31 ` [RFC PATCH v2 07/11] dma-mapping: Add flags to dma_map_ops to indicate PCI P2PDMA support Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-13  2:36   ` Ira Weiny
2021-03-13  2:36     ` Ira Weiny
2021-03-13  2:36     ` Ira Weiny
2021-03-15 16:33     ` Logan Gunthorpe
2021-03-15 16:33       ` Logan Gunthorpe
2021-03-15 16:33       ` Logan Gunthorpe
2021-03-16  8:00       ` Christoph Hellwig
2021-03-16  8:00         ` Christoph Hellwig
2021-03-16  8:00         ` Christoph Hellwig
2021-03-16  8:15   ` Christoph Hellwig
2021-03-16  8:15     ` Christoph Hellwig
2021-03-16  8:15     ` Christoph Hellwig
2021-03-11 23:31 ` [RFC PATCH v2 08/11] iommu/dma: Support PCI P2PDMA pages in dma-iommu map_sg Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-12 15:52   ` Robin Murphy
2021-03-12 15:52     ` Robin Murphy
2021-03-12 15:52     ` Robin Murphy
2021-03-12 17:03     ` Logan Gunthorpe
2021-03-12 17:03       ` Logan Gunthorpe
2021-03-12 17:03       ` Logan Gunthorpe
2021-03-12 19:47       ` Robin Murphy
2021-03-12 19:47         ` Robin Murphy
2021-03-12 19:47         ` Robin Murphy
2021-03-12 20:06         ` Logan Gunthorpe [this message]
2021-03-12 20:06           ` Logan Gunthorpe
2021-03-12 20:06           ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 09/11] block: Add BLK_STS_P2PDMA Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-16  8:00   ` Christoph Hellwig
2021-03-16  8:00     ` Christoph Hellwig
2021-03-16  8:00     ` Christoph Hellwig
2021-03-16 16:02     ` Logan Gunthorpe
2021-03-16 16:02       ` Logan Gunthorpe
2021-03-16 16:02       ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 10/11] nvme-pci: Check DMA ops when indicating support for PCI P2PDMA Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31 ` [RFC PATCH v2 11/11] nvme-pci: Convert to using dma_map_sg for p2pdma pages Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:31   ` Logan Gunthorpe
2021-03-11 23:59   ` Jason Gunthorpe
2021-03-11 23:59     ` Jason Gunthorpe
2021-03-11 23:59     ` Jason Gunthorpe
2021-03-12  1:37     ` Logan Gunthorpe
2021-03-12  1:37       ` Logan Gunthorpe
2021-03-12  1:37       ` Logan Gunthorpe
2021-03-12 15:51 ` [RFC PATCH v2 00/11] Add support to dma_map_sg for P2PDMA Robin Murphy
2021-03-12 15:51   ` Robin Murphy
2021-03-12 15:51   ` Robin Murphy
2021-03-12 16:18   ` Logan Gunthorpe
2021-03-12 16:18     ` Logan Gunthorpe
2021-03-12 16:18     ` Logan Gunthorpe
2021-03-12 17:46     ` Robin Murphy
2021-03-12 17:46       ` Robin Murphy
2021-03-12 17:46       ` Robin Murphy
2021-03-12 18:24       ` Logan Gunthorpe
2021-03-12 18:24         ` Logan Gunthorpe
2021-03-12 18:24         ` Logan Gunthorpe

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=6dd679b3-e38b-2c18-1990-bfc96bb4d971@deltatee.com \
    --to=logang@deltatee.com \
    --cc=andrzej.jakowski@intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dave.b.minturn@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=iweiny@intel.com \
    --cc=jason@jlekstrand.net \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=jianxin.xiong@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sbates@raithlin.com \
    --cc=willy@infradead.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 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.