Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node

On Tue, Jun 28, 2022 at 07:59:39AM +, Shameerali Kolothum Thodi wrote: > Now that we have all the required acks, could you please pick this series via > IOMMU tree? Applied to core branch, thanks. ___ iommu mailing list

Re: [PATCH 0/5] iommu/virtio: Add identity domains

On Thu, Oct 14, 2021 at 03:00:38AM +, Tian, Kevin wrote: > I saw a concept of deferred attach in iommu core. See iommu_is_ > attach_deferred(). Currently this is vendor specific and I haven't > looked into the exact reason why some vendor sets it now. Just > be curious whether the same reason

Re: [PATCH v7 00/12] Clean up "mediatek,larb"

On Mon, Aug 09, 2021 at 08:30:03AM +, Yong Wu (吴勇) wrote: > Thanks very much for your confirm. I will your Ack for iommu part in > the next version. Note that my ack is conditional on the premise that Matthias has reviewed the IOMMU parts. Thanks, Joerg

Re: [PATCH v6 0/9] ACPI/IORT: Support for IORT RMR node

On Tue, Jul 27, 2021 at 06:51:56AM +, Shameerali Kolothum Thodi wrote: > A gentle ping on this... This needs more reviews, and please add Will Deacon when you post the next version of this patch-set. Regards, Joerg ___ iommu

Re: [PATCH v14 0/6] iommu: Enhance IOMMU default DMA mode build options

Hi John, On Fri, Jun 25, 2021 at 05:41:09PM +0100, John Garry wrote: > We think that this series is ready to go. > > There would be a build conflict with the following: > https://lore.kernel.org/linux-iommu/20210616100500.174507-1-na...@vmware.com/ > > So please let us know where you stand on

Re: [PATCH v4 0/2] VMD MSI Remapping Bypass

On Wed, Mar 17, 2021 at 07:14:17PM +, Derrick, Jonathan wrote: > Gentle reminder, for v5.13 ? This should go through the PCI tree, Bjorn? ___ iommu mailing list iommu@lists.linux-foundation.org

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

On Tue, Nov 03, 2020 at 01:48:51PM -0400, Jason Gunthorpe wrote: > I think the same PCI driver with a small flag to support the PF or > VF is not the same as two completely different drivers in different > subsystems There are counter-examples: ixgbe vs. ixgbevf. Note that also a single driver

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote: > This whole thread was brought up by IDXD which has a SVA driver and > now wants to add a vfio-mdev driver too. SVA devices that want to be > plugged into VMs are going to be common - this architecture that a SVA > driver cannot

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote: > The point is that other places beyond VFIO need this Which and why? > Sure, but sometimes it is necessary, and in those cases the answer > can't be "rewrite a SVA driver to use vfio" This is getting to abstract. Can you come up

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote: > On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote: > > So having said this, what is the benefit of exposing those SVA internals > > to user-space? > > Only the device use of the PASID is device

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote: > > From: Jason Wang > > Jason suggest something like /dev/sva. There will be a lot of other > > subsystems that could benefit from this (e.g vDPA). Honestly, I fail to see the benefit of offloading these IOMMU specific setup tasks to

Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits

On Wed, Jul 22, 2020 at 12:34:57PM +, Sironi, Filippo wrote: > On Wed, 2020-07-22 at 14:19 +0200, j...@8bytes.org wrote: > I wouldn't be surprised if a PCIe device raises a PCIe SERR if it is > asked to do DMA beyond its abilities. Yeah, but that would also make it impossible

Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits

On Fri, Jul 17, 2020 at 03:15:43PM +, Sironi, Filippo wrote: > I don't believe that we want to trust a userspace driver here, this may > result in hosts becoming unstable because devices are asked to do things > they aren't meant to do (e.g., DMA beyond 48 bits). How is the hosts stability

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

Hi Jonathan, Hi Daniel, On Fri, Apr 17, 2020 at 01:14:30AM +, Derrick, Jonathan wrote: > Hi Daniel> I should have CCed you on this, but it should temporarily resolve > that > issue: > https://lists.linuxfoundation.org/pipermail/iommu/2020-April/043253.html Yes, this is an issue in the

Re: [RFC PATCH 11/34] iommu: Split off default domain allocation from group assignment

Hi Jonathan, On Mon, Apr 13, 2020 at 10:10:50PM +, Derrick, Jonathan wrote: > I had to add the following for initial VMD support. The new PCIe domain > added on VMD endpoint probe didn't have the dev_iommu member set on the > VMD subdevices, which I'm guessing is due to probe_iommu_group

Re: iommu: amd: Simpify decoding logic for INVALID_PPR_REQUEST event

On Mon, Oct 14, 2019 at 08:06:19PM +, Suthikulpanit, Suravee wrote: > Reuse existing macro to simplify the code and improve readability. > > Cc: Joerg Roedel > Cc: Gary R Hook > Signed-off-by: Suravee Suthikulpanit > --- > drivers/iommu/amd_iommu.c | 3 +-- > 1 file changed, 1

Re: iommu: amd: Fix incorrect PASID decoding from event log

On Mon, Oct 14, 2019 at 08:06:05PM +, Suthikulpanit, Suravee wrote: > IOMMU Event Log encodes 20-bit PASID for events: > ILLEGAL_DEV_TABLE_ENTRY > IO_PAGE_FAULT > PAGE_TAB_HARDWARE_ERROR > INVALID_DEVICE_REQUEST > as: > PASID[15:0] = bit 47:32 > PASID[19:16] = bit

Re: [PATCH] iommu/vt-d: Add Scalable Mode fault information

On Tue, Sep 10, 2019 at 05:30:09PM +, Mehta, Sohil wrote: > On Tue, 2019-09-10 at 10:08 +0200, Joerg Roedel wrote: > > > + "Unknown", "Unknown", "Unknown", "Unknown", "Unknown", > > "Unknown", "Unknown", /* 0x49-0x4F */ > > > > Maybe add the number (0x49-0x4f) to the respecting "Unknown"

Re: [PATCH] iommu/amd: Re-factor guest virtual APIC (de-)activation code

On Tue, Jul 23, 2019 at 07:00:37PM +, Suthikulpanit, Suravee wrote: > Re-factore the logic for activate/deactivate guest virtual APIC mode (GAM) > into helper functions, and export them for other drivers (e.g. SVM). > to support run-time activate/deactivate of SVM AVIC. > > Cc: Joerg Roedel

Re: [PATCH] iommu/amd: Add support for X2APIC IOMMU interrupts

Hi Suravee, On Tue, Jul 16, 2019 at 04:29:16AM +, Suthikulpanit, Suravee wrote: > AMD IOMMU requires IntCapXT registers to be setup in order to generate > its own interrupts (for Event Log, PPR Log, and GA Log) with 32-bit > APIC destination ID. Without this support, AMD IOMMU MSI interrupts

Re: [PATCH] svm/avic: iommu/amd: Flush IOMMU IRT after update all entries

On Wed, Mar 20, 2019 at 08:14:56AM +, Suthikulpanit, Suravee wrote: > When AVIC is enabled and the VM has discrete device assignment, > the interrupt remapping table (IRT) is used to keep track of which > destination APIC ID the IOMMU will inject the device interrput to. > > This means every

Re: [PATCH V5 0/3] x86/Hyper-V/IOMMU: Add Hyper-V IOMMU driver to support x2apic mode

On Mon, Feb 25, 2019 at 08:51:22PM +, Michael Kelley wrote: > Joerg -- What's your take on this patch set now that it has settled down? If > you are good with it, from the Microsoft standpoint we're hoping that it > can get into linux-next this week (given the extra week due to 5.0-rc8). I

Re: [PATCH] iommu/ipmmu-vmsa: fix device reference leaks

Adding a few more people to Cc. On Sun, Feb 03, 2019 at 10:27:09AM +, wen yang wrote: > Make sure to drop the reference to the device taken by > of_find_device_by_node() on driver unbind. > > Signed-off-by: Wen Yang > Cc: Joerg Roedel > Cc: iommu@lists.linux-foundation.org > Cc:

Re: [PATCH v3] iommu: amd: Fix IOMMU page flush when detach device from a domain

On Thu, Jan 24, 2019 at 02:17:34PM +, Suthikulpanit, Suravee wrote: > On 1/24/19 9:11 PM, j...@8bytes.org wrote: > > On Thu, Jan 24, 2019 at 04:16:45AM +, Suthikulpanit, Suravee wrote: > >> drivers/iommu/amd_iommu.c | 15 +++ > >> 1 file c

Re: [PATCH v3] iommu: amd: Fix IOMMU page flush when detach device from a domain

On Thu, Jan 24, 2019 at 04:16:45AM +, Suthikulpanit, Suravee wrote: > drivers/iommu/amd_iommu.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) Applied, thanks Suravee. ___ iommu mailing list

Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain

Hi Suravee, On Thu, Jan 24, 2019 at 03:25:19AM +, Suthikulpanit, Suravee wrote: > Actually, I just noticed that device_flush_dte() has already handled flushing > the DTE > for alias device as well. Please see the link below. > >

Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain

Hi Suravee, On Tue, Jan 22, 2019 at 03:53:18PM +, Suthikulpanit, Suravee wrote: > Thanks for the detail. Alright then, let's just go with the version you > sent on 1/16/19. Do you want me to resend V3 with that changes, or > would you be taking care of that? Please send me a v3 based on the

Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain

Hi Suravee, On Thu, Jan 17, 2019 at 08:44:36AM +, Suthikulpanit, Suravee wrote: > Then, in __domain_flush_pages, we issue command when the dev_iommu[] >= 0. > This should preserve previous behavior, and only add flushing condition to > the specific IOMMU in detached state. Please let me know

Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain

On Wed, Jan 16, 2019 at 02:40:59PM +, Suthikulpanit, Suravee wrote: > Actually, device_flush_dte(alias) should be needed regardless of this patch. > Are you planning to add this? Yes, I stumbled over this while writing the diff. I'll submit that as a separate patch. Thanks, Joerg

Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain

On Wed, Jan 16, 2019 at 02:08:55PM +, Suthikulpanit, Suravee wrote: > Actually, I am not sure how we would be missing the flush on the last device. > In my test, I am seeing the flush command being issued correctly during > vfio_unmap_unpin(), which is after all devices are detached. >

Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain

On Wed, Jan 16, 2019 at 04:16:25AM +, Suthikulpanit, Suravee wrote: > diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c > index 525659b88ade..ab31ba75da1b 100644 > --- a/drivers/iommu/amd_iommu.c > +++ b/drivers/iommu/amd_iommu.c > @@ -1248,7 +1248,13 @@ static void

Re: [PATCH] iommu/amd: Mark translation invalid during device detach

Hi Suravee, On Wed, Jan 16, 2019 at 04:15:10AM +, Suthikulpanit, Suravee wrote: > From: Suravee Suthikulpanit > > When a device switches domain, IOMMU driver detach device from the old > domain, and attach device to the new domain. During this period > the host table root pointer is not

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

On Tue, Dec 11, 2018 at 01:35:23PM +, Jean-Philippe Brucker wrote: > > /* So we need a iommu_aux_detach_all()? */ > > This could be useful for device drivers that want to do bulk cleanup on > device removal. If they rely on Function Level Reset to disable PASID > states for example, they

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

On Tue, Dec 11, 2018 at 06:34:23PM +, Jean-Philippe Brucker wrote: > The cost of enabling those features for a device does seem negligible. > For the SMMU we need to allocate about 70k of additional memory for the > initial PASID table, but enabling the PASID cap shouldn't add any > overhead

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi Lu Baolu, On Mon, Dec 10, 2018 at 10:57:22AM +0800, Lu Baolu wrote: > > /* Check if a device supports a given feature of the IOMMU-API */ > > bool iommu_dev_has_feature(struct device *dev, enum iommu_dev_features > > *feat); > > Here we pass in a pointer of "enum iommu_dev_features",

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi Kevin, On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote: > Can I interpret above as that you agree with the aux domain concept (i.e. one > device can be linked to multiple domains) in general, and now we're just > trying > to address the remaining open in API level? Yes, I thouht

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi, On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote: > btw Baolu just reminded me one thing which is worthy of noting here. > 'primary' vs. 'aux' concept makes sense only when we look from a device > p.o.v. That binding relationship is not (*should not be*) carry-and-forwarded > cross

Re: [PATCH 0/2] iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist()

On Wed, Nov 28, 2018 at 09:23:35AM +, Yoshihiro Shimoda wrote: > Yoshihiro Shimoda (2): > iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist() to check SoC > revisions > iommu/ipmmu-vmsa: add an array of slave devices whitelist Applied, thanks.

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi Jean-Philippe, On Wed, Nov 21, 2018 at 07:05:13PM +, Jean-Philippe Brucker wrote: > For the moment though, I think we should allow device drivers to use the > DMA-API at the same time as SVA. Yeah, that makes sense. > If a device driver has to map a management ring buffer for example, >

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi Kevin, On Thu, Nov 22, 2018 at 08:39:19AM +, Tian, Kevin wrote: > I agree special action needs to be taken for everything else (other than > DMA-API), but the point that I didn't get is why the action must be based > a new SVA-type domain, instead of extending default domain with SVA >

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote: > Can you please elaborate a bit more about the concept of subdomains? > From my point of view, an aux-domain is a normal un-managed domain which > has a PASID and could be attached to any ADIs through the aux-domain > specific

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi Jean-Philippe, On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote: > (1) My initial approach would have been to use the same page tables for > the default_domain and this new domain, but it might be precisely what > you were trying to avoid with this new proposal: a device

Re: [PATCH] amd/iommu: Fix Guest Virtual APIC Log Tail Address Register

On Mon, Nov 12, 2018 at 12:26:30PM +, Suthikulpanit, Suravee wrote: > From: Filippo Sironi > > This register should have been programmed with the physical address > of the memory location containing the shadow tail pointer for > the guest virtual APIC log instead of the base address. > >

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

Hi, On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote: > Hi Joerg, > > On 11/7/18 12:25 AM, j...@8bytes.org wrote: > Nowadays, we can find PASID granular DMA translation on both ARM and x86 > platforms. With PASID granular DMA translation supported in system iommu, if >

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote: > To me, that sounds like a very good argument for having separate "attach as > primary domain" and "attach as aux domain" APIs. I agree with that, overloading iommu_attach_device() to support aux-domains is not going to be a

Re: [PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU

Hi Nipun, On Thu, Jun 21, 2018 at 03:59:27AM +, Nipun Gupta wrote: > Will this patch-set be taken for the next kernel release (and via which tree)? I can take this through IOMMU tree if nobody objects. Please work out the last remaining comment on patch 7 with Robin and then re-send with all

Re: [PATCH 02/37] iommu/sva: Bind process address spaces to devices

On Tue, Feb 13, 2018 at 12:57:23PM +, Jean-Philippe Brucker wrote: > * bind_device() fails if the device's group has more than one device, > otherwise calls __bind_device(). This prevents device drivers that are > oblivious to IOMMU groups from opening a backdoor. > > * bind_group() calls

Re: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

On Thu, Apr 27, 2017 at 03:34:06PM +, Zhuo, Qiuxu wrote: > It looks like the printk is misleading and it’s nothing actually > failed, but just it isn’t copying if the new kernel is not a kdump > kernel. Yes, that is true. But the messages are harmless and you are safe to ignore them in your

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

On Tue, Mar 21, 2017 at 04:30:55PM +, Deucher, Alexander wrote: > > I am preparing a debug-patch that disables ATS for these GPUs so someone > > with such a chip can test it. > > Thanks Joerg. Here is a debug patch, using the hard hammer of disabling the use of ATS completly in the AMD IOMMU

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

On Tue, Mar 21, 2017 at 04:17:40PM +, Deucher, Alexander wrote: > > -Original Message- > > From: 'j...@8bytes.org' [mailto:j...@8bytes.org] > > Sent: Tuesday, March 21, 2017 12:11 PM > > To: Deucher, Alexander > > Cc: Alex Deucher;

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

On Tue, Mar 21, 2017 at 04:01:53PM +, Deucher, Alexander wrote: > It seems to only affect Stoney systems, but not others (Carrizo, > Bristol, etc.). Maybe we could just disable it on Stoney until we > root cause it. Completion-wait loop timeouts indicate something is seriously wrong. How can

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

On Fri, Mar 17, 2017 at 11:53:09AM -0400, Alex Deucher wrote: > On Fri, Mar 17, 2017 at 8:15 AM, Daniel Drake wrote: > > Hi, > > > > On Mon, Mar 13, 2017 at 2:01 PM, Deucher, Alexander > > wrote: > >> > We are unable to boot Acer Aspire E5-553G (AMD

Re: [PATCH 2/2] iommu/amd: Destroy api_lock mutex when freeing domain

On Thu, Jun 09, 2016 at 03:48:44PM +, Vesely, Jan wrote: > On Sat, 2016-05-21 at 14:11 -0400, Jan Vesely wrote: > > From: Jan Vesely > > > > Signed-off-by: Jan Vesely > > --- > >  drivers/iommu/amd_iommu.c | 1 + > >  1 file changed, 1 insertion(+) > >

Re: RFC: extend IOMMU attributes

On Thu, Feb 18, 2016 at 04:16:26PM +, Stuart Yoder wrote: > #define IOMMU_READ(1 << 0) > #define IOMMU_WRITE (1 << 1) > -#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */ > +#define IOMMU_CACHE_COHERENT (1 << 2) /* cacheable and coherent */ > #define

Re: [PATCH v6 0/3] arm64: IOMMU-backed DMA mapping

Hi Robin, On Tue, Oct 13, 2015 at 01:12:46PM +0100, Robin Murphy wrote: > Anyway, what are your thoughts on taking this for 4.4? Since the > dependencies are now in and we're at -rc5 already, I'm on the verge > of reposting a self-contained version to go through arm64, as we > really need to

Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table

Hi Nan, On Mon, Aug 24, 2015 at 06:26:33AM +, Xiao, Nan (Nan@HPS Performance, Beijing) wrote: drivers/iommu/intel-iommu.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 0649b94..4213598 100644

Re: [PATCH] Documentation/Intel-IOMMU.txt: Modify definition of DRHD

Hi Nan, I applied this patch with some formatting fixes, thanks. Details below: From: Xiao, Nan (Nan@HPS Performance, Beijing) nan.x...@hp.com git-am made this author-line out of your patch: (Nan@HPS (Nan@HPS Which doesn't even look like a valid email address. I fixed it, but please include a

Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table

On Tue, Aug 25, 2015 at 08:46:27AM +, Xiao, Nan (Nan@HPservers-Core-OE-PSC) wrote: Yes, your patch is simple and better! Okay, I queued this patch to my x86/vt-d branch: From 03932776424a799c3f065a69e98076a78530288b Mon Sep 17 00:00:00 2001 From: Joerg Roedel jroe...@suse.de Date: Tue, 25

Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table

On Tue, Aug 25, 2015 at 09:15:39AM +, Xiao, Nan (Nan@HPservers-Core-OE-PSC) wrote: In commit message: There is a bug in iommu_context_addr() which will always use the lower context table, event when the upper context table needs to be used. Fix this issue. I think it should be

Re: [PATCH v5 1/3] iommu: Implement common IOMMU ops for DMA mapping

Hi Will, On Thu, Aug 06, 2015 at 04:23:27PM +0100, Will Deacon wrote: We're quite keen to get this in for arm64, since we're without IOMMU DMA ops and need to get something upstream. Do you think this is likely to be merged for 4.3/4.4 or would we be better off doing our own arch-private

Re: [iommu:ppc/pamu 1/1] drivers/iommu/fsl_pamu.h:24:32: fatal error: asm/fsl_pamu_stash.h: No such file or directory

Hi Varun, On Tue, May 05, 2015 at 05:57:32PM +, Varun Sethi wrote: Actually PPC32 dependency is incorrect, that's what Emil's patch removed. As a result PAMU driver got built on other platforms as well. commit f2fafdd954d743a0e68e5cd76dbef2f2454deefa PAMU driver should depend on

Re: IOMMU/DMA API inquiry

Hi Mark, On Tue, Feb 17, 2015 at 02:48:03PM -0500, Mark Hounschell wrote: I understand that AMD IOMMU support is not available for 32-bit kernels. I believe the INTEL IOMMU is supported there. Not knowing why, I was curious if that is going to remain that way? Yes, I have no plan on making

Re: [PATCH] iommu: arm-smmu: avoid build warning

On Mon, Feb 02, 2015 at 10:20:49AM +, Will Deacon wrote: On Fri, Jan 30, 2015 at 09:55:55PM +, Arnd Bergmann wrote: - reg = (iova ~0xfff) 32; + reg = ((u64)iova ~0xfff) 32; writel_relaxed(reg, cb_base + ARM_SMMU_CB_ATS1PR_HI); } Thanks,

Re: [PATCH v2] iommu/ipmmu-vmsa: Use the ARM LPAE page table allocator

On Wed, Jan 21, 2015 at 05:31:05PM +0200, Laurent Pinchart wrote: On Wednesday 21 January 2015 16:27:24 j...@8bytes.org wrote: On Wed, Jan 21, 2015 at 05:07:03PM +0200, Laurent Pinchart wrote: As you wish. I just thought you would prefer merging the series with at least one user. Yes

Re: [PATCH v2] iommu/ipmmu-vmsa: Use the ARM LPAE page table allocator

On Wed, Jan 21, 2015 at 04:58:12PM +0200, Laurent Pinchart wrote: All my other ipmmu patches have been queued by Joerg in his next branch, on which this patch is based. If you base your series on the same branch you can just queue this patch on top of it. Do you plan to submit the result to

Re: [PATCH v2] iommu/ipmmu-vmsa: Use the ARM LPAE page table allocator

On Wed, Jan 21, 2015 at 05:07:03PM +0200, Laurent Pinchart wrote: As you wish. I just thought you would prefer merging the series with at least one user. Yes, and with your patch there would be two users: ARM-SMMU and the VMSA IPMMU. So ideally I would apply/pull Will's patches on v3.19-rc5

Re: [PATCH v2 0/5] Generic IOMMU page table framework

Hi Will, On Fri, Jan 16, 2015 at 02:01:31PM +, Will Deacon wrote: I've not received any feedback on this revision of the series, but it's working well for me and Laurent showed that it works with his IOMMU too. Joerg -- can I include this in my pull request for 3.20, or is there

Re: [PATCH v2 0/5] Generic IOMMU page table framework

On Mon, Jan 19, 2015 at 03:56:42PM +0200, Laurent Pinchart wrote: Yes, and I've rebased them (or actually it, it's a single patch) on v2. I haven't had time to test the result yet, I'll try to do so later tonight or tomorrow. Great! Would be good if this can go upstream with more than one

Re: [v3 00/26] Add VT-d Posted-Interrupts support

Hi Feng, On Tue, Jan 06, 2015 at 01:10:19AM +, Wu, Feng wrote: Ping... Hi Joerg David, Could you please have a look at the IOMMU part of this series (patch 02 - 04, patch 06 - 09 , patch 26)? Hi Thomas, Ingo, Peter, Could you please have a look at this series, especially for

Re: [PATCH v1 1/1] iommu/amd: set iommu for early mapped ioapic/hpet

On Mon, Sep 01, 2014 at 02:17:44PM +0800, Su, Friendy wrote: diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 3783e0b..148ab61 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -747,7 +747,7 @@ static int __init

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

On Tue, Aug 12, 2014 at 09:56:11AM -0700, Olav Haugan wrote: On 8/12/2014 3:48 AM, Rob Clark wrote: iirc, one plan for 'flags' was some sort of DONT_FLUSH_TLB flag for drivers which wanted to map/unmap N buffers with a single flush at the end. There might have been some other usages

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

On Mon, Aug 18, 2014 at 01:48:46PM -0700, Olav Haugan wrote: On 8/18/2014 11:32 AM, Rob Clark wrote: No, I do not have other uses right now. But could imagine use cases like force insert minimum mapping size here mapping flag etc. I think it is worth discussing to add a flush() function to

Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.

On Sun, Jul 06, 2014 at 07:25:18PM +, Gabbay, Oded wrote: Once we can agree on that, than I think we can agree that kfd and hmm can and should be bounded to mm struct and not file descriptors. The file descriptor concept is the way it works in the rest of the kernel. It works for numerous

Re: hpsa driver bug crack kernel down!

Hey David, On Mon, Apr 14, 2014 at 05:03:51PM +, Woodhouse, David wrote: Jiang, if you can then let me have a copy with a signed-off-by I'll shepherd it upstream along with your other patch which is already in my iommu-2.6.git tree. What is the state of these fixes? I plan to send out a

Re: hpsa driver bug crack kernel down!

On Wed, Apr 16, 2014 at 01:58:44PM +, Woodhouse, David wrote: On Wed, 2014-04-16 at 15:37 +0200, j...@8bytes.org wrote: What is the state of these fixes? I plan to send out a pull-request before easter and hoped to include these fixes as well. I'm travelling and was going to do some

Re: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes required by the PAMU driver.

On Tue, Apr 30, 2013 at 05:09:32PM +, Sethi Varun-B16395 wrote: Would you take this patchset for 3.10 merge? Not this time. The final patch came in very late and is pretty big too. For code of that size I would like to have a few weeks more testing in next and probably also a non-Freescale

Re: [v3 1/1] iommu/tegra: smmu: Support variable MMIO ranges/blocks

On Mon, Feb 04, 2013 at 09:54:07PM +0100, Hiroshi Doyu wrote: Hiroshi Doyu hd...@nvidia.com wrote @ Mon, 04 Feb 2013 22:39:21 +0200 (EET): Upon reflection, that comment probably isn't correct, since the only way to know where each register range begins, relative to the register numbers

Re: [PATCH 2/2] ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver

On Wed, Jan 25, 2012 at 08:39:32AM +0100, Hiroshi Doyu wrote: From: Hiroshi DOYU hd...@nvidia.com Date: Thu, 17 Nov 2011 07:31:31 +0200 Subject: [PATCH 2/2] ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit). This patch implements