[patch] iommu/vt-d: fix a loop in prq_event_thread()
There is an extra semi-colon on this if statement so we always break on
the first iteration.
Fixes: 0204a4960982 ('iommu/vt-d: Add callback to device driver on page faults')
Signed-off-by: Dan Carpenter
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 99a7803..dd070e6 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -536,7 +536,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
/* Accounting for major/minor faults? */
rcu_read_lock();
list_for_each_entry_rcu(sdev, &svm->devs, list) {
- if (sdev->sid == PCI_DEVID(req->bus, req->devfn));
+ if (sdev->sid == PCI_DEVID(req->bus, req->devfn))
break;
}
/* Other devices can go away, but the drivers are not permitted
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.0 address=0x000000fdf9103300 flags=0x0600]
"Works with..." On Fri, Oct 16, 2015 at 3:02 PM, G. Richard Bellamy wrote: > With with virtualization enabled and running. > > On Fri, Oct 16, 2015 at 2:02 AM, Joerg Roedel wrote: > >> On Thu, Oct 15, 2015 at 11:28:03PM -0700, G. Richard Bellamy wrote: >> > Applied the patch, and no longer receiving the kernel error messages. >> Haven't >> > tried to do anything with my VMs yet, but thought you'd want to know >> sooner >> > than later. >> >> Okay, thanks. It is possible that the issue only happens when you start >> a VM, so it would be great if you could test this too. >> >> >> Thanks, >> >> Joerg >> >> > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.0 address=0x000000fdf9103300 flags=0x0600]
With with virtualization enabled and running. On Fri, Oct 16, 2015 at 2:02 AM, Joerg Roedel wrote: > On Thu, Oct 15, 2015 at 11:28:03PM -0700, G. Richard Bellamy wrote: > > Applied the patch, and no longer receiving the kernel error messages. > Haven't > > tried to do anything with my VMs yet, but thought you'd want to know > sooner > > than later. > > Okay, thanks. It is possible that the issue only happens when you start > a VM, so it would be great if you could test this too. > > > Thanks, > > Joerg > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] arm64: Use gfpflags_allow_blocking()
On Fri, 16 Oct 2015 16:33:42 +0100 Robin Murphy wrote:
> __GFP_WAIT is going away to live its life under a new identity; convert
> __iommu_alloc_attrs() to the new helper function instead.
>
> ...
>
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -566,7 +566,7 @@ static void *__iommu_alloc_attrs(struct device *dev,
> size_t size,
>*/
> gfp |= __GFP_ZERO;
>
> - if (gfp & __GFP_WAIT) {
> + if (gfpflags_allow_blocking(gfp)) {
> struct page **pages;
> pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, coherent);
Seems unnecessarily elaborate. What's wrong with
---
a/arch/arm64/mm/dma-mapping.c~mm-page_alloc-rename-__gfp_wait-to-__gfp_reclaim-arm-fix
+++ a/arch/arm64/mm/dma-mapping.c
@@ -562,7 +562,7 @@ static void *__iommu_alloc_attrs(struct
*/
gfp |= __GFP_ZERO;
- if (gfp & __GFP_WAIT) {
+ if (gfp & __GFP_RECLAIM) {
struct page **pages;
pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, coherent);
?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch] iommu/vt-d: shift wrapping bug in prq_event_thread()
On Thu, 2015-10-15 at 21:25 +0300, Dan Carpenter wrote:
> The "req->addr" variable is a bit field declared as "u64 addr:52;".
> The "address" variable is a u64. We need to cast "req->addr" to a u64
> before the shift or the result is truncated to 52 bits.
>
> Fixes: 0b9252a34858 ('iommu/vt-d: Implement page request handling')
> Signed-off-by: Dan Carpenter
Applied; thanks.
> Also does this code work if PAGE_SHIFT is more than 12? (I am a newbie
> so this is not rhetorical, I don't know the answer).
Er, no it doesn't. That should have been VTD_PAGE_SHIFT, not PAGE_SHIFT
— and then it *will* always be 12. Thanks for pointing it out.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] arm64: Use gfpflags_allow_blocking()
On Fri, Oct 16, 2015 at 04:33:42PM +0100, Robin Murphy wrote: > __GFP_WAIT is going away to live its life under a new identity; convert > __iommu_alloc_attrs() to the new helper function instead. > > CC: Mel Gorman > CC: Andrew Morton > Reported-by: Sudeep Holla > Signed-off-by: Robin Murphy Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] arm64: Workaround renaming of __GFP_WAIT
On Fri, Oct 16, 2015 at 04:33:41PM +0100, Robin Murphy wrote: > The imminent renaming of __GFP_WAIT in the mm tree conflicts with its > use in the new IOMMU DMA ops; introduce a temporary local version of > its replacement to smooth over the transition. > > This patch should be reverted at 4.4-rc1. > > CC: Mel Gorman > CC: Andrew Morton > Reported-by: Sudeep Holla > Signed-off-by: Robin Murphy Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/2] arm64: Use gfpflags_allow_blocking()
__GFP_WAIT is going away to live its life under a new identity; convert
__iommu_alloc_attrs() to the new helper function instead.
CC: Mel Gorman
CC: Andrew Morton
Reported-by: Sudeep Holla
Signed-off-by: Robin Murphy
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 66444df..40cd4af 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -566,7 +566,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t
size,
*/
gfp |= __GFP_ZERO;
- if (gfp & __GFP_WAIT) {
+ if (gfpflags_allow_blocking(gfp)) {
struct page **pages;
pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, coherent);
--
1.9.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/2] arm64: Workaround renaming of __GFP_WAIT
The imminent renaming of __GFP_WAIT in the mm tree conflicts with its use in the new IOMMU DMA ops; introduce a temporary local version of its replacement to smooth over the transition. This patch should be reverted at 4.4-rc1. CC: Mel Gorman CC: Andrew Morton Reported-by: Sudeep Holla Signed-off-by: Robin Murphy --- Sudeep points out that there are pending changes in -next touching arm64 which I hadn't spotted, which end up breaking the build when merged with my changes in the IOMMU tree. Catalin, would you mind acking these fixes so that Joerg can carry them? We should be able to send the revert through arm64 once the dust has settled. Thanks, Robin. --- arch/arm64/mm/dma-mapping.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index 6320361..66444df 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -546,6 +546,10 @@ static void flush_page(struct device *dev, const void *virt, phys_addr_t phys) __dma_flush_range(virt, virt + PAGE_SIZE); } +#ifdef __GFP_WAIT +#define gfpflags_allow_blocking(gfp) ((gfp) & __GFP_WAIT) +#endif + static void *__iommu_alloc_attrs(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs) -- 1.9.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] iommu/arm-smmu: Updates for 4.4
On Thu, Oct 15, 2015 at 05:16:22PM +0100, Will Deacon wrote: > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git > for-joerg/arm-smmu/updates > > for you to fetch changes up to 166bdbd23161160f2abcea70621adba179050bee: Pulled, thanks Will. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.0 address=0x000000fdf9103300 flags=0x0600]
On Thu, Oct 15, 2015 at 11:28:03PM -0700, G. Richard Bellamy wrote: > Applied the patch, and no longer receiving the kernel error messages. Haven't > tried to do anything with my VMs yet, but thought you'd want to know sooner > than later. Okay, thanks. It is possible that the issue only happens when you start a VM, so it would be great if you could test this too. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
