Re: [PATCHv6 3/7] ARM: dma-mapping: implement dma sg methods on top of any generic dma ops

On Fri, Feb 10, 2012 at 07:58:40PM +0100, Marek Szyprowski wrote: This patch converts all dma_sg methods to be generic (independent of the current DMA mapping implementation for ARM architecture). All dma sg operations are now implemented on top of respective dma_map_page/dma_sync_single_for*

Re: [PATCH 05/16] iommu/amd: Split device table initialization into irq and dma part

On Fri, Sep 28, 2012 at 02:23:55PM +0200, Joerg Roedel wrote: When the IOMMU is enabled very early (as with irq-remapping) some devices are still in BIOS hand. When dma is blocked early this can cause lots of IO_PAGE_FAULTs. So delay the DMA initialization and do it right before the dma_ops

Re: [PATCH 07/16] iommu/amd: Add IRTE invalidation routine

On Fri, Sep 28, 2012 at 02:23:57PM +0200, Joerg Roedel wrote: Add routine to invalidate the IOMMU cache for interupt translations. Also include the IRTE caches when flushing all IOMMU caches. Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/iommu/amd_iommu.c | 27

Re: [PATCH 08/16] iommu/amd: Add routines to manage irq remapping tables

On Fri, Sep 28, 2012 at 02:23:58PM +0200, Joerg Roedel wrote: Add routines to: * Alloc remapping tables and single entries from these tables * Change entries in the tables * Free entries in the table Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/iommu/amd_iommu.c |

Re: [PATCH 09/16] iommu/amd: Add IOAPIC remapping routines

On Fri, Sep 28, 2012 at 02:23:59PM +0200, Joerg Roedel wrote: Add the routine to setup interrupt remapping for ioapic interrupts. Also add a routine to change the affinity of an irq and to free an irq allocation for interrupt remapping. The last two functions will also be used for MSI

Re: [PATCH 10/16] iommu/amd: Implement MSI routines for interrupt remapping

On Fri, Sep 28, 2012 at 02:24:00PM +0200, Joerg Roedel wrote: Add routines to setup interrupt remapping for MSI interrupts. Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/iommu/amd_iommu.c | 74 + 1 file changed, 74

Re: [PATCH 09/16] iommu/amd: Add IOAPIC remapping routines

On Mon, Oct 01, 2012 at 10:40:51AM +0200, Joerg Roedel wrote: On Fri, Sep 28, 2012 at 10:45:15AM -0400, Konrad Rzeszutek Wilk wrote: On Fri, Sep 28, 2012 at 02:23:59PM +0200, Joerg Roedel wrote: + /* + * Mask level triggered irqs. + * Use IRQ_DELAYED_DISABLE for edge triggered irqs

Re: [PATCH 00/19 v4] Improve IRQ remapping abstraction in x86 core code

/317 I looked at the patches and you can also add Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com If you have a git tree I would like to test them as well. Thx. Changes from v3-v4: * Rebased to v3.7-rc6 * Added Acked-bys * Fixed problems with AMD IRQ remapping

Re: [PATCH 0/3] AMD IOMMUv2 Performance Counter patches

On Mon, Jan 21, 2013 at 02:20:55PM -0600, Steven L. Kinney wrote: From: Steven L. Kinney steven.kin...@amd.com These patches implement the AMD IOMMUv2.5 Performance Counter functionality via custom perf PMU and implement static counting for various IOMMU translations. The patches address

Re: RFC: vfio / iommu driver for hardware with no iommu

On Sat, Apr 27, 2013 at 12:22:28PM +0800, Andrew Cooks wrote: On Fri, Apr 26, 2013 at 6:23 AM, Don Dutile ddut...@redhat.com wrote: On 04/24/2013 10:49 PM, Sethi Varun-B16395 wrote: -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-

Re: RFC: vfio / iommu driver for hardware with no iommu

Does vfio work with swiotlb and if not, can/should swiotlb be extended? Or does the time and space overhead make it a moot point? It does not work with SWIOTLB as it uses the DMA API, not the IOMMU API. I think you got it reversed. vfio uses iommu api, not dma api. Right. That is what I

Re: [PATCH 2/2] vfio: hugepage support for vfio_iommu_type1

+ * Turns out AMD IOMMU has a page table bug where it won't map large pages + * to a region that previously mapped smaller pages. This should be fixed + * soon, so this is just a temporary workaround to break mappings down into + * PAGE_SIZE. Better to map smaller pages than nothing. + */

Re: [PATCH 0/2] vfio: type1 iommu hugepage support

On Fri, May 24, 2013 at 11:24:26AM -0600, Alex Williamson wrote: This series let's the vfio type1 iommu backend take advantage of iommu large page support. See patch 2/2 for the details. This has been tested on both amd_iommu and intel_iommu, but only my AMD system has large page support.

Re: [PATCH 4/9] xen: Add xen_create_contiguous_region

On Wed, Nov 13, 2013 at 10:50:58AM +, Liu, Jijiang wrote: Hi, I have a question about xen_create_contiguous_region function, in which kernel version was it introduced? You can use 'git annotate' to figure out which commit introduced it. Then you can use 'git tag --contains commit' to

Re: [RFC] dma-mapping: dma_alloc_coherent_mask return dma_addr_t

On Tue, Dec 10, 2013 at 04:05:37PM +, Stefano Panella wrote: When running a 32bit kernel there are still some pci devices capable of 64bit addressing (eg. sound/pci/hda/hda_intel.c) If these drivers are setting: dev-coherent_dma_mask = 0x why dma_alloc_coherent_mask

Re: [PATCH v2 1/5] x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled

is specified. So this fixes it by unconditionally zeroing the allocated memory region. Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: David Woodhouse dw...@infradead.org Cc: Don Dutile ddut...@redhat.com Cc: Thomas Gleixner t

Re: [PATCH v2 2/5] x86: enable DMA CMA with swiotlb

On Fri, Jan 17, 2014 at 08:32:09AM +0900, Akinobu Mita wrote: 2014/1/16 Konrad Rzeszutek Wilk konrad.w...@oracle.com: On Tue, Jan 14, 2014 at 11:13:47PM +0900, Akinobu Mita wrote: The DMA Contiguous Memory Allocator support on x86 is disabled when swiotlb config option is enabled. So DMA

RE: [RFC PATCH v4 01/10] driver core: export driver_probe_device()

On Mar 6, 2014 5:25 PM, Stuart Yoder stuart.yo...@freescale.com wrote: -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, February 20, 2014 4:44 PM To: Yoder Stuart-B08248 Cc: Antonios Motakis; alex.william...@redhat.com;

Re: mechanism to allow a driver to bind to any device

On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote: Hi Greg, We (Linaro, Freescale, Virtual Open Systems) are trying get an issue closed that has been perculating for a while around creating a mechanism that will allow kernel drivers like vfio can bind to devices of any type.

Re: mechanism to allow a driver to bind to any device

On Wed, Mar 26, 2014 at 11:06:02PM +0800, Alexander Graf wrote: Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk konrad.w...@oracle.com: On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote: Hi Greg, We (Linaro, Freescale, Virtual Open Systems) are trying get

Re: mechanism to allow a driver to bind to any device

On Wed, Mar 26, 2014 at 10:21:02AM -0600, Alex Williamson wrote: On Wed, 2014-03-26 at 23:06 +0800, Alexander Graf wrote: Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk konrad.w...@oracle.com: On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote: Hi Greg

Re: mechanism to allow a driver to bind to any device

On Wed, Mar 26, 2014 at 10:49:52AM -0600, Alex Williamson wrote: On Wed, 2014-03-26 at 12:32 -0400, Konrad Rzeszutek Wilk wrote: On Wed, Mar 26, 2014 at 10:21:02AM -0600, Alex Williamson wrote: On Wed, 2014-03-26 at 23:06 +0800, Alexander Graf wrote: Am 26.03.2014 um 22:40 schrieb

Re: mechanism to allow a driver to bind to any device

On Wed, Mar 26, 2014 at 04:09:21PM -0600, Alex Williamson wrote: On Wed, 2014-03-26 at 10:21 -0600, Alex Williamson wrote: On Wed, 2014-03-26 at 23:06 +0800, Alexander Graf wrote: Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk konrad.w...@oracle.com: On Wed, Mar 26

Re: [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

On Fri, May 16, 2014 at 10:48:00AM -0400, Konrad Rzeszutek Wilk wrote: On Fri, May 9, 2014 at 12:50 PM, Alex Williamson alex.william...@redhat.com wrote: The driver_override field allows us to specify the driver for a device ... ... Signed-off-by: Alex Williamson alex.william

Re: [PATCH v4 1/1] iommu-api: Add map_sg/unmap_sg functions

On Thu, Jul 31, 2014 at 05:54:44PM -0700, Olav Haugan wrote: Mapping and unmapping are more often than not in the critical path. map_sg and unmap_sg allows IOMMU driver implementations to optimize the process of mapping and unmapping buffers into the IOMMU page tables. Instead of mapping a

Re: [PATCH v4 1/1] iommu-api: Add map_sg/unmap_sg functions

On Thu, Aug 07, 2014 at 02:52:56PM -0700, Olav Haugan wrote: On 8/6/2014 11:24 PM, Thierry Reding wrote: On Wed, Aug 06, 2014 at 04:28:45PM -0700, Olav Haugan wrote: On 8/6/2014 1:17 PM, Joerg Roedel wrote: On Wed, Aug 06, 2014 at 10:08:55AM -0700, Olav Haugan wrote: so you are suggesting

Re: [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions

On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote: Mapping and unmapping are more often than not in the critical path. map_sg and unmap_sg allows IOMMU driver implementations to optimize the process of mapping and unmapping buffers into the IOMMU page tables. Instead of mapping a

Re: [RFC PATCH 07/20] x86/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X

On Tue, Aug 12, 2014 at 03:26:00PM +0800, Yijing Wang wrote: Introduce a new struct msi_chip apic_msi_chip instead of weak arch functions to configure MSI/MSI-X in x86. Why not 'x86_msi_ops' (see arch/x86/kernel/x86_init.c) Signed-off-by: Yijing Wang wangyij...@huawei.com ---

Re: [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions

On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote: On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote: On 8/19/2014 9:11 AM, Laurent Pinchart wrote: On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote: On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If

Re: [Xen-devel] [PATCH v1 08/21] x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq

people. Ok, it all makes sense now. Acked-by: David Vrabel david.vra...@citrix.com You can also add 'Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com' on the whole series - I ran it through on Xen and on baremetal with a mix of 32/64 builds. Oh, and also Reviewed-by: Konrad

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Is there a git tree for these patches? Currently, there are a lot of weak arch functions in MSI code. Thierry Reding

Re: [PATCH v2 04/22] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()

s/wiil/will. in the later patch. Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com I don't even remember testing it - I guess I did the earlier version. So a couple of questions since I've totally forgotten about this: diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 50f67a3

Re: [PATCH v3 0/5] enhance DMA CMA on x86

On Tue, Sep 30, 2014 at 09:49:54PM -0400, Peter Hurley wrote: On 09/30/2014 07:45 PM, Thomas Gleixner wrote: Whether the proposed patchset is the correct solution to support it is a completely different question. This patchset has been in mainline since 3.16 and has already caused

Re: [PATCH v3 0/5] enhance DMA CMA on x86

On Fri, Oct 03, 2014 at 08:08:33AM +0900, Akinobu Mita wrote: 2014-10-03 7:03 GMT+09:00 Peter Hurley pe...@hurleysoftware.com: On 10/02/2014 12:41 PM, Konrad Rzeszutek Wilk wrote: On Tue, Sep 30, 2014 at 09:49:54PM -0400, Peter Hurley wrote: On 09/30/2014 07:45 PM, Thomas Gleixner wrote

Re: Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]

...@gmail.com wrote: On 17 April 2015 at 22:06, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote: On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: And easier way is to compile the kernel

Re: [PATCH 0/6] IOMMU/DMA map_resource support for peer-to-peer

On Fri, May 08, 2015 at 04:46:17PM -0400, Mark Hounschell wrote: On 05/08/2015 04:21 PM, Konrad Rzeszutek Wilk wrote: On Fri, May 01, 2015 at 01:32:12PM -0500, wda...@nvidia.com wrote: From: Will Davis wda...@nvidia.com Hi, This patch series adds DMA APIs to map and unmap a struct

Re: [PATCH 3/6] dma-mapping: pci: add pci_(un)map_resource

On Thu, May 07, 2015 at 10:19:05AM -0500, Bjorn Helgaas wrote: [+cc Dave for sparc64, Yinghai] On Fri, May 01, 2015 at 01:32:15PM -0500, wda...@nvidia.com wrote: From: Will Davis wda...@nvidia.com Simply route these through to the new dma_(un)map_resource APIs. Signed-off-by: Will

Re: Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]

On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote: On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG and then load the attached module. That should tell you who and what else

Re: [PATCH v2 4/7] DMA-API: Add dma_(un)map_resource() documentation

On Mon, May 18, 2015 at 01:25:01PM -0500, wda...@nvidia.com wrote: From: Will Davis wda...@nvidia.com Add references to both the general API documentation as well as the HOWTO. Signed-off-by: Will Davis wda...@nvidia.com --- Documentation/DMA-API-HOWTO.txt | 39

Re: [PATCH] iommu/amd: Fix amd_iommu_detect() (does not fix any issues).

On Mon, Aug 31, 2015 at 06:13:03PM -0400, j.gli...@gmail.com wrote: > From: Jérôme Glisse > > Fix amd_iommu_detect() to return positive value on success, like > intended, and not zero. This will not change anything in the end > as AMD IOMMU disable swiotlb and properly

Re: [PATCH] iommu/amd: Fix amd_iommu_detect() (does not fix any issues).

On Tue, Oct 27, 2015 at 09:53:30AM +0900, Jerome Glisse wrote: > On Tue, Oct 27, 2015 at 09:47:48AM +0900, Jerome Glisse wrote: > > On Mon, Oct 26, 2015 at 12:07:17PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Mon, Aug 31, 2015 at 06:13:03PM -0400, j.gli...@gmail.com wrote: &g

Re: [RFC PATCH] dma/swiotlb: Add helper for device driver to opt-out from swiotlb.

On Thu, Sep 17, 2015 at 03:02:51PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 17, 2015 at 02:22:38PM -0400, jgli...@redhat.com wrote: > > From: Jérôme Glisse <jgli...@redhat.com> > > > > The swiotlb dma backend is not appropriate for some devices like > >

Re: [RFC PATCH] dma/swiotlb: Add helper for device driver to opt-out from swiotlb.

locations? > > Signed-off-by: Jérôme Glisse <jgli...@redhat.com> > To: iommu@lists.linux-foundation.org > Cc: Joerg Roedel <jroe...@suse.de> > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Cc: Alex Deucher <alexander.deuc...@amd.com> >

Re: [RFC PATCH] dma/swiotlb: Add helper for device driver to opt-out from swiotlb.

On Thu, Sep 17, 2015 at 03:07:47PM -0400, Jerome Glisse wrote: > On Thu, Sep 17, 2015 at 03:02:51PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 17, 2015 at 02:22:38PM -0400, jgli...@redhat.com wrote: > > > From: Jérôme Glisse <jgli...@redhat.com> > > &g

Re: [RFC PATCH] dma/swiotlb: Add helper for device driver to opt-out from swiotlb.

On Thu, Sep 17, 2015 at 03:11:14PM -0400, Jerome Glisse wrote: > On Thu, Sep 17, 2015 at 03:06:57PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 17, 2015 at 03:02:51PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Thu, Sep 17, 2015 at 02:22:38PM -0400, jgli...@redhat.com w

Re: Fwd: SWIOTLB on 32-bit PAE.

On Sat, Oct 03, 2015 at 09:36:30AM -0500, Bjorn Helgaas wrote: > [+cc Konrad, Joerg, iommu list] > > On Fri, Oct 02, 2015 at 04:20:16PM +0200, Christian Melki wrote: > > I discovered a strange error on my machine. 32-bit PAE 4.2.0 without > > IOMMU code (yeah, I know). > > When writing to an ext4

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote: > The dma-mapping core and the implementations do not change the > DMA attributes passed by pointer. Thus the pointer can point to const > data. However the attributes do not have to be a bitfield. Instead > unsigned long will

Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource

On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas Söderlund wrote: > Hi Konrad, > > Thanks for your feedback. > > On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote: > > > > > > -In some circumstances dma_map_single() and dma_map_page() will fail

Re: [PATCHv6 2/8] dma-debug: add support for resource mappings

> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t > size, > + int direction, dma_addr_t dma_addr) > +{ > + struct dma_debug_entry *entry; > + > + if (unlikely(dma_debug_disabled())) > + return; > + > + entry =

Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource

> > -In some circumstances dma_map_single() and dma_map_page() will fail to create > -a mapping. A driver can check for these errors by testing the returned > -DMA address with dma_mapping_error(). A non-zero return value means the > mapping > -could not be created and the driver should take

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: > Provide support so that kexec can be used to boot a kernel when SME is > enabled. Is the point of kexec and kdump to ehh, dump memory ? But if the rest of the memory is encrypted you won't get much, will you? Would it make sense to

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

On Thu, Feb 16, 2017 at 09:46:19AM -0600, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [RFC Design Doc v3] Enable Shared Virtual Memory feature in pass-through scenarios

On Wed, Nov 30, 2016 at 08:49:24AM +, Liu, Yi L wrote: > What's changed from v2: > a) Detailed feature description > b) refine description in "Address translation in virtual SVM" > b) "Terms" is added > > Content > === > 1. Feature description > 2.

Re: [PATCH 1/1] arch/x86: Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt

On Thu, Sep 29, 2016 at 11:18:34AM -0700, Glenn Serre wrote: > Good morning, > > On 09/29/2016 11:11 AM, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 29, 2016 at 09:58:55AM -0700, Glenn Serre wrote: > > > Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt > > > > &

Re: [PATCH 1/1] arch/x86: Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt

On Thu, Sep 29, 2016 at 09:58:55AM -0700, Glenn Serre wrote: > Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt > > Allow default to iommu=pt without adding to command line. > Add iommu=nopt to turn off default. What's the reason / use-case for it? > > Signed-off-by: Glenn Serre >

Re: [PATCH v1 1/1] arch/x86: Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt

On Tue, Oct 04, 2016 at 10:00:50AM -0700, Glenn Serre wrote: > Good afternoon, > > On 10/04/2016 09:52 AM, Konrad Rzeszutek Wilk wrote: > > On Tue, Oct 04, 2016 at 09:11:39AM -0700, Glenn Serre wrote: > > > Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt > > > > &

Re: [PATCH v1 1/1] arch/x86: Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt

On Tue, Oct 04, 2016 at 09:11:39AM -0700, Glenn Serre wrote: > Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt > > Allow default to iommu=pt without adding to command line. > Add iommu=nopt to turn off default. > > The reason we use iommu=pt is to support using the DPDK igb_uio driver, > which we need

Re: [PATCH 1/2] swiotlb: Rate-limit printing when running out of SW-IOMMU space

On Mon, Oct 31, 2016 at 04:45:03PM +0100, Geert Uytterhoeven wrote: > If the system runs out of SW-IOMMU space, changes are high successive > requests will fail, too, flooding the kernel log. This is true > especially for streaming DMA, which is typically used repeatedly outside > the driver's

Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option

On Mon, Oct 31, 2016 at 04:45:04PM +0100, Geert Uytterhoeven wrote: > On architectures like arm64, swiotlb is tied intimately to the core > architecture DMA support. In addition, ZONE_DMA cannot be disabled. > > To aid debugging and catch devices not supporting DMA to memory outside > the 32-bit

Re: [RFC Design Doc v3] Enable Shared Virtual Memory feature in pass-through scenarios

.snip.. > > > Shared Virtual Memory feature in pass-through scenarios is actually SVM > > > virtualization. It is to let application programs(running in guest)share > > > their > > > virtual address with assigned device(e.g. graphics processors or > > > accelerators). > > > > I think I am

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On June 15, 2017 11:33:22 AM EDT, Borislav Petkov wrote: >On Thu, Jun 15, 2017 at 09:59:45AM -0500, Tom Lendacky wrote: >> Actually the detection routine, amd_iommu_detect(), is part of the >> IOMMU_INIT_FINISH macro support which is called early through >mm_init() >> from

Re: [PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops

-xen.c | 14 --- > drivers/xen/swiotlb-xen.c | 93 > ++ > include/xen/swiotlb-xen.h | 62 +--- > 4 files changed, 49 insertions(+), 137 deletions(-) Yeeey! Revi

Re: [PATCH 08/44] xen-swiotlb: implement ->mapping_error

On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote: > DMA_ERROR_CODE is going to go away, so don't rely on it. Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> ___ iommu mailing list iommu@lists.linux-foundation.

Re: [PATCH v6] vfio: platform: reset: Add Broadcom FlexRM reset module

On Tue, Aug 29, 2017 at 09:34:46AM +0530, Anup Patel wrote: > This patch adds Broadcom FlexRM low-level reset for > VFIO platform. > Is there an document that explains and /or details the various registers? > It will do the following: > 1. Disable/Deactivate each FlexRM ring > 2. Flush each

Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

On Tue, Oct 17, 2017 at 10:02:50AM +0200, Geert Uytterhoeven wrote: > Hi Shimoda-san, > > CC iommu > > On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda > wrote: > > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling") > > deletes the bounce

Re: No check of the size passed to unmap_single in swiotlb

..snip.. > > There doesn't seem to be much good reason for SWIOTLB to be more special > > than other DMA API backends, and not all of them have enough internal state > > to > > be able to make such a check. It's also not necessarily possible to "prevent > > damage" anyway - if a driver does pass

Re: No check of the size passed to unmap_single in swiotlb

On Mon, Nov 20, 2017 at 08:17:14AM +, Eric Yang wrote: > Hi all, Hi! > > During debug a device only support 32bits DMA(Qualcomm Atheros AP) in our > LS1043A 64bits ARM SOC, we found that the invoke of dma_unmap_single --> > swiotlb_tbl_unmap_single will unmap the passed "size" anyway

Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

..snip.. > > > > > > Anyway, I made v2 patches by using swiotlb related definitions. Would you > > > check it? > > > > Did I miss that email? As in was I cc-ed? > > This was my fault. When I submitted v2 patches, I didn't include your email > and iommu mailing list... No problem. > > > >

Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

On Fri, Nov 03, 2017 at 03:01:12PM +0100, Geert Uytterhoeven wrote: > Hi Konrad, > > On Fri, Nov 3, 2017 at 2:23 PM, Konrad Rzeszutek Wilk <kon...@kernel.org> > wrote: > > ..snip.. > >> > > > >> > > Anyway, I made v2 patches by using

Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

19, 2017 5:34 PM > > > > > > Hi Konrad, > > > > > > On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk > > > <kon...@darnok.org> wrote: > < snip > > > > >> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c > > &

Re: [PATCH] swiotlb: Update the comment of swiotlb

On Wed, May 09, 2018 at 01:39:57PM +0200, Christoph Hellwig wrote: > On Wed, May 09, 2018 at 05:08:30PM +0800, Yisheng Xie wrote: > > Hi Christoph, > > > > On 2018/5/9 15:38, Christoph Hellwig wrote: > > > Thanks, > > > > > > applied to the dma-mapping tree. > > > > Thanks > > > > BTW, should

Re: [PATCH 3/6] swiotlb: merge swiotlb_unmap_page and unmap_single

On Tue, May 15, 2018 at 08:05:20PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Applied. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/6] swiotlb: remove a pointless comment

On Tue, May 15, 2018 at 08:05:18PM +0200, Christoph Hellwig wrote: > This comments describes an aspect of the map_sg interface that isn't > even exploited by swiotlb. > > Signed-off-by: Christoph Hellwig Applied. > --- > lib/swiotlb.c | 6 -- > 1 file changed, 6 deletions(-) >

Re: [PATCH 2/6] swiotlb: do not panic on mapping failures

On Tue, May 15, 2018 at 08:05:19PM +0200, Christoph Hellwig wrote: > We now have error handling in map_single/map_page callers (most of them Which ones are missing? Shouldn't we first fix those before we rip this out? > anyway). As swiotlb_tbl_map_single already prints a useful warning > when

Re: [PATCH] MAINTAINERS: add the iommu list for swiotlb and xen-swiotlb

h...@lst.de> I am so behind emails.. I am not sure if I had replied to this, but just in case I hadn't: Acked-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> P.S. I am behind on the review of your dma rework - really sorry it is taking that long. > --- > MAINTAINERS | 3 ++- >

Re: swiotlb cleanup (resend)

On Mon, Aug 27, 2018 at 08:33:08PM +0200, Christoph Hellwig wrote: > On Mon, Aug 27, 2018 at 02:13:11PM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Jul 25, 2018 at 01:37:56PM +0200, Christoph Hellwig wrote: > > > Hi Konrad, > > > > > > below are a few sw

Re: [RFC PATCH 11/11] powerpc/svm: Increase SWIOTLB buffer size

On Fri, Aug 24, 2018 at 01:25:35PM -0300, Thiago Jung Bauermann wrote: > From: Anshuman Khandual > > SWIOTLB buffer default size (64MB) is not enough for large sequential write > operations which eventually leads to kernel crash like here. > > virtio-pci :00:05.0: swiotlb buffer is full

Re: swiotlb cleanup (resend)

On Wed, Jul 25, 2018 at 01:37:56PM +0200, Christoph Hellwig wrote: > Hi Konrad, > > below are a few swiotlb patches. Mostly just cleanups, but the removal > of the panic option is an actual change in (rarely used) functionality. > > I'd be happy to pick them up through the dma-mapping tree if

Re: [PATCH 05/20] swiotlb: allow the architecture to provide a get_required_mask hook

f-by: Christoph Hellwig Reviewed-by: Konrad Rzeszutek Wilk Thank you! > --- > kernel/dma/swiotlb.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c > index 904541055792..1bb420244753 100644 > --- a/kernel/dma/sw

Re: [PATCH] swiotlb: Clean up reporting

On Tue, Jul 10, 2018 at 04:22:22PM -0700, Kees Cook wrote: > This removes needless use of '%p', and refactors the printk calls to > use pr_*() helpers instead. > > Signed-off-by: Kees Cook Reviewed-by: Konrad Rzeszutek Wilk Christoph, volunteered to pick this patch up in his tre

Re: [PATCH 21/33] dma-mapping: add an arch_dma_supported hook

Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > --- > arch/x86/include/asm/dma-mapping.h | 3 +++ > arch/x86/kernel/pci-dma.c | 19 --- > include/linux/dma-mapping.h| 11 +++ > 3 files changed, 26 insertions(+), 7 delet

Re: [PATCH 05/22] x86: rename swiotlb_dma_ops

On Wed, Jan 10, 2018 at 09:09:15AM +0100, Christoph Hellwig wrote: > We'll need that name for a generic implementation soon. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > --- > arch/x86/kernel/pci-s

Re: [PATCH 19/33] dma-mapping: warn when there is no coherent_dma_mask

f-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > --- > include/linux/dma-mapping.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index d84951865b

Re: [PATCH 04/22] powerpc: rename swiotlb_dma_ops

On Wed, Jan 10, 2018 at 09:09:14AM +0100, Christoph Hellwig wrote: > We'll need that name for a generic implementation soon. > Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Signed-off-by: Christoph Hellwig <h...@lst.de> > --- > arch/powerpc/include/a

Re: [PATCH 03/22] ia64: rename swiotlb_dma_ops

On Wed, Jan 10, 2018 at 09:09:13AM +0100, Christoph Hellwig wrote: > We'll need that name for a generic implementation soon. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > --- > arch/ia64/hp/common/hw

Re: [PATCH 06/22] swiotlb: rename swiotlb_free to swiotlb_exit

On Wed, Jan 10, 2018 at 09:09:16AM +0100, Christoph Hellwig wrote: OK? Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Signed-off-by: Christoph Hellwig <h...@lst.de> > --- > arch/powerpc/kernel/dma-swiotlb.c | 2 +- > arch/x86/kernel/pci-swiotlb.c

Re: [PATCH 05/14] x86/amd_gart: look at coherent_dma_mask instead of GFP_DMA

t; Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Signed-off-by: Christoph Hellwig <h...@lst.de> > --- > arch/x86/kernel/amd_gart_64.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86

Re: [PATCH 11/14] swiotlb: remove swiotlb_set_mem_attributes

On Thu, Mar 15, 2018 at 01:51:59PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 14, 2018 at 06:52:10PM +0100, Christoph Hellwig wrote: > > Now that set_memory_decrypted is always available we can just call it > > directly. > > > > Won't this break ARM build?

Re: [PATCH 11/14] swiotlb: remove swiotlb_set_mem_attributes

On Wed, Mar 14, 2018 at 06:52:10PM +0100, Christoph Hellwig wrote: > Now that set_memory_decrypted is always available we can just call it > directly. > Won't this break ARM build? ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH 10/14] set_memory.h: provide set_memory_{en,de}crypted stubs

On Wed, Mar 14, 2018 at 06:52:09PM +0100, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Thank you! > --- > include/linux/set_memory.h | 12 > 1 file changed, 12 inser

Re: [PATCH 01/13] x86: remove X86_PPRO_FENCE

rom enabling the workaround. > > Get rid of it for good. > RIP. > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Thank you! ___ iommu mailing list io

Re: [PATCH 02/13] x86: remove dma_alloc_coherent_mask

On Mon, Mar 05, 2018 at 09:46:44AM -0800, Christoph Hellwig wrote: > These days all devices (including the ISA fallback device) have a coherent > DMA mask set, so remove the workaround. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <k

Re: [PATCH 10/12] arm: don't build swiotlb by default

On Mon, Apr 23, 2018 at 07:04:17PM +0200, Christoph Hellwig wrote: > swiotlb is only used as a library of helper for xen-swiotlb if Xen support > is enabled on arm, so don't build it by default. > CCing Stefano > Signed-off-by: Christoph Hellwig > --- > arch/arm/Kconfig | 3 ++- >

Re: [PATCH 11/12] swiotlb: move the SWIOTLB config symbol to lib/Kconfig

ll > make the usage optional for a few architectures that want this feature > to be user selectable. If I follow this select business this will enable it on ARM and x86 by default. As such: Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Thank you! > > Signed-off-by: Chr

Re: [PATCH] swiotlb: swiotlb_{alloc,free}_buffer should depend on CONFIG_DMA_DIRECT_OPS

On Sat, Mar 24, 2018 at 06:03:51PM +0100, Christoph Hellwig wrote: > On Fri, Mar 23, 2018 at 02:57:07PM -0400, Konrad Rzeszutek Wilk wrote: > > On Fri, Mar 23, 2018 at 06:49:30PM +0100, Christoph Hellwig wrote: > > > Otherwise we might get unused symbol warnings for

Re: use generic dma-direct and swiotlb code for x86 V3

On Tue, Mar 20, 2018, 5:03 AM Ingo Molnar wrote: > > * Christoph Hellwig wrote: > > > On Tue, Mar 20, 2018 at 09:37:51AM +0100, Ingo Molnar wrote: > > > > git://git.infradead.org/users/hch/misc.git dma-direct-x86 > > > > > > Btw., what's the upstreaming route for

Re: [PATCH] swiotlb: swiotlb_{alloc,free}_buffer should depend on CONFIG_DMA_DIRECT_OPS

On Fri, Mar 23, 2018 at 06:49:30PM +0100, Christoph Hellwig wrote: > Otherwise we might get unused symbol warnings for configs that built > swiotlb.c only for use by xen-swiotlb.c and that don't otherwise select > CONFIG_DMA_DIRECT_OPS, which is possible on arm. > > Fixes: 16e73adbca76

Re: use generic dma-direct and swiotlb code for x86 V3

On Tue, Mar 20, 2018 at 04:16:00PM +0100, Christoph Hellwig wrote: > On Tue, Mar 20, 2018 at 11:25:21AM +0000, Konrad Rzeszutek Wilk wrote: > > Are you testing with swiotlb=force? > > I've done swiotlb=force testing with earlier versions, and otherwise > relied on a VM with more

Re: [PATCH] x86: enable swiotlb for > 4GiG ram on 32-bit kernels

Reviewed-by: Konrad Rzeszutek Wilk But since it is already in 'tip' feel free to ignore my tag. Thanks! --- arch/x86/kernel/pci-swiotlb.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c index 661583662430..71c0b01d93b1 1

  1   2   3   >