Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 15/04/17 04:17 PM, Benjamin Herrenschmidt wrote: > You can't. If the iommu is on, everything is remapped. Or do you mean > to have dma_map_* not do a remapping ? Well, yes, you'd have to change the code so that iomem pages do not get remapped and the raw BAR address is passed to the DMA

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 15/04/17 09:01 PM, Benjamin Herrenschmidt wrote: > Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a > flag ?) Well you can't use ZONE_DEVICE as an indicator. They may be regular RAM, (eg. pmem). It would need a separate flag indicating it is backed by iomem. Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote: > I'm wondering, since this is limited to support behind a single > switch, if you could have a software-iommu hanging off that switch > device object that knows how to catch and translate the non-zero > offset bus address case. We have

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote: > Thanks, Benjamin, for the summary of some of the issues. > > On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote > > So I assume the p2p code provides a way to address that too via special > > dma_ops ? Or wrappers ? > > Not at this

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sat, Apr 15, 2017 at 10:41 AM, Logan Gunthorpe wrote: > Thanks, Benjamin, for the summary of some of the issues. > > On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote >> So I assume the p2p code provides a way to address that too via special >> dma_ops ? Or wrappers ? > >

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

Thanks for the information Milan. On 15/04/17 06:10 AM, Milan Broz wrote: > I think your patch is ok (if it is just plain conversion), if it is > really needed, we can switch to ahash later in follow-up patch. Sounds good to me. > p.s. > there is a lot of lists on cc, but for this patch is

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

Thanks, Benjamin, for the summary of some of the issues. On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote > So I assume the p2p code provides a way to address that too via special > dma_ops ? Or wrappers ? Not at this time. We will probably need a way to ensure the iommus do not attempt to

[GIT PULL] SCSI fixes for 4.11-rc6

This is larger than it would be: we missed the -rc5 fixes pull request because of a problem linux-next found with the lowest patch which necessitated a rebase to fix. This is seven small fixes which are all for user visible issues that fortunately only occur in rare circumstances. The most

Re: [PATCH] scsi: storvsc: Allow only one remove lun work item to be issued per lun

Just add a singlethreaded workqueue for storvsc_handle_error and you'll get serialization for all error handling for free.

[PATCH] scsi: storvsc: Allow only one remove lun work item to be issued per lun

When running multipath on a VM if all available paths go down the driver can schedule large amounts of storvsc_remove_lun work items to the same lun. In response to the failing paths typically storvsc responds by taking host->scan_mutex and issuing a TUR per lun. If there has been heavy IO to the

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On 04/14/2017 06:03 PM, Logan Gunthorpe wrote: > > > On 14/04/17 02:39 AM, Christoph Hellwig wrote: >> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: >>> Very straightforward conversion to the new function in all four spots. >> >> I think the right fix here is to switch