Re: move the arm arch_dma_alloc implementation to common code
Can I get a quick review from the arm64 folks? I think it should be fine there as it basically is a code move, but an additional pair or two of eyes always helps to weed out bugs. On Mon, Nov 05, 2018 at 01:19:22PM +0100, Christoph Hellwig wrote: > Hi all, > > this series moves the existing arm64 implementation of arch_dma_alloc and > arch_dma_free to common code given that it is not arm64-specific, and > then also uses it for csky. Given how many architectures remap memory > for the DMA coherent implementation it should be usable for many more, > and the new cache flushing hook and the generic atomic pool are also > enablers for implementing the IOMMU API dma ops in common code in a > follow on series. > ___ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu ---end quoted text--- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 9/9] csky: use the generic remapping dma alloc implementation
On Tue, Nov 06, 2018 at 03:01:41PM +0800, Guo Ren wrote: > > + return dma_atomic_pool_init(GFP_KERNEL, pgprot_noncached(PAGE_KERNEL)); > > } > > postcore_initcall(atomic_pool_init); > Seems also could remove atomic_pool_init from csky, why not put them in > common? The code basically moved to common code, but the architecture needs to pick the gfp mask (GFP_DMA32 on arm vs GFP_KERNEL on csky for example) and the pgprot it needs for uncached remappings. > Reviewed-by: Guo Ren > > Compile is OK, qemu boot OK. Functions are the same and just move to common. Thanks for your review! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: iommu/io-pgtable-arm-v7s: About pagetable 33bit PA
On Thu, 2018-11-08 at 13:49 +, Robin Murphy wrote:
> On 08/11/2018 07:31, Yong Wu wrote:
> > Hi Robin,
> >
> > After the commit ad67f5a6545f ("arm64: replace ZONE_DMA with
> > ZONE_DMA32"), we don't have ZONE_DMA in aarch64, but
> > __arm_v7s_alloc_table[1] use the GFP_DMA to expect the physical address
> > of pagetable should be 32bit.
> >
> > Right now we meet a issue that the lvl1 pagetable PA is 0x1_3ab6_ in
> > the 4GB broad. then the IOMMU initialize failed.(This issue can be fixed
> > if we revert ad67f5a6545f.)
>
> But that shouldn't actually be failing on MTK platforms anyway, right,
> since your IOMMU is still capable of addressing that? Seems like we
> overlooked that check in __arm_v7s_alloc_table(), where the conversion
> by casting will want updating to something like
> "iopte_to_paddr(paddr_to_iopte(...))" in patch #4 of your series.
The current mt8183 IOMMU support the pagetable address over 4GB.
Unfortunately the previous mt8173 don't support.(mt8173 IOMMU support
mapping for the dram over 4GB while its pagetable still need locate
below 4GB.)
In order to unify the code, we still expect lvl2 pagetable base don't
over 4GB. thus I didn't change it in the current patchset.
>
> > I planed to add GFP_DMA32 for pagetable allocation. the level1 was
> > ok but level2 was failed. It looks that slab don't like GFP_DMA32[2].
> > this is the warning log:
> > =
> > Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x488020 (GFP_ATOMIC|
> > __GFP_ZERO). Fix your code!
> > =
> > I don't know why slab don't allow GFP_DMA32, the gfp flags seems only
> > be bypassed to alloc_page. Is it possible that let slab allow GFP_DMA32
> > for aarch64?
> I had a bit of a look into it some time ago, and I don't recall seeing
> any obvious reason that the kmem_cache API couldn't support ZONE_DMA32
> in general (either via a separate SLAB_CACHE_DMA32, or just overloading
> SLAB_CACHE_DMA depending on which of CONFIG_ZONE_DMA/CONFIG_ZONE_DMA32
> are enabled) - I guess that's just never been implemented since nobody
> needed it before.
Thanks for the comment. We could try a patch for this.
>
> Robin.
>
> > We notice that this has been discussed[3]. but if we use alloc_page for
> > the level2 pagetable, It may waste lots of memory.
> >
> > Any suggestion is appreciated.
> >
> >
> > Reported-by: Nicolas Boichat
> >
> > [1]
> > https://elixir.bootlin.com/linux/v4.20-rc1/source/drivers/iommu/io-pgtable-arm-v7s.c#L200
> > [2] https://elixir.bootlin.com/linux/v4.20-rc1/source/mm/internal.h#L37
> > [3] https://patchwork.kernel.org/patch/10474289/
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 06/10] swiotlb: use swiotlb_map_page in swiotlb_map_sg_attrs
On Tue, Nov 06, 2018 at 05:27:14PM -0800, John Stultz wrote: > But at that point if I just re-apply "swiotlb: use swiotlb_map_page in > swiotlb_map_sg_attrs", I reproduce the hangs. > > Any suggestions for how to further debug what might be going wrong > would be appreciated! Very odd. In the end map_sg and map_page are defined to do the same things to start with. The only real issue we had in this area was: "[PATCH v2] of/device: Really only set bus DMA mask when appropriate" so with current mainline + that you still see a problem, and if you rever the commit we are replying to it still goes away? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Zero pages manually in a length of scatterlist
On Tue, Nov 06, 2018 at 02:39:26PM +, Robin Murphy wrote: > ...and I have some significant objections to that simplification which I > plan to respond with ;) > > (namely that it defaults the whole higher-order page allocation business > which will have varying degrees of performance impact on certain cases) Well, please place your objection there. The behavior does match what every other iommu-based dma ops implementation ouside of arm/arm64 does, so there is some precedent for it to say the least. But if the only current users objects I'll surely find a way to accomodate it, but a good rationale including numbers would be useful to document it. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC] iommu/vt-d: Group and domain relationship
Hi James, Regards to the relationship of iommu group and domain, the blog written by Alex may help you. The blog explained very well on how iommu group is determined and why. http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- > boun...@lists.linux-foundation.org] On Behalf Of James Sewart via iommu > Sent: Thursday, November 8, 2018 7:30 PM > Subject: Re: [RFC] iommu/vt-d: Group and domain relationship > > Hey, > > > On 8 Nov 2018, at 01:42, Lu Baolu wrote: > > > > Hi, > > > > On 11/8/18 1:55 AM, James Sewart wrote: > >> Hey, > >>> On 7 Nov 2018, at 02:10, Lu Baolu wrote: > >>> > >>> Hi, > >>> > >>> On 11/6/18 6:40 PM, James Sewart wrote: > Hey Lu, > Would you be able to go into more detail about the issues with [...] > >>> > >>> Why do we want to open this door? Probably we want the generic iommu > >>> layer to handle these things (it's called default domain). > >> I’d like to allocate a domain and attach it to multiple devices in a > >> group/multiple groups so that they share address translation, but still > >> allow drivers for devices in those groups to use the dma_map_ops api. > > > > Just out of curiosity, why do you want to share a single domain across > > multiple groups? By default, the groups and DMA domains are normally > > 1-1 mapped, right? > > Currently we see each device in a group with their own domain. > find_or_alloc_domain looks at dma aliases to determine who shares domains > whereas pci_device_group in the generic iommu code determines groups using > a few other checks. We have observed internally that devices under a pcie > switch will be put in the same group but they do not share a domain within > that group. Really? iommu group is DMA isolation unit. You said they are not sharing a domain. Do you mean they have different IOVA address space by mentioning they are not sharing a domain? Is there any special things(e.g. special IOVA allocation to avoid unexpected P2P) done on your system? Normally, devices within an iommu group should share an IOVA address space. Thanks, Yi Liu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor support
Hi,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, November 9, 2018 9:40 AM
> Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
> support
>
> Hi,
>
> On 11/8/18 3:20 PM, Liu, Yi L wrote:
> > Hi,
> >
> >> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >> Sent: Thursday, November 8, 2018 2:14 PM
> >>
> >> Hi,
> >>
> >> On 11/8/18 1:45 PM, Liu, Yi L wrote:
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, November 8, 2018 1:25 PM
> Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation
> descriptor support
>
> Hi,
>
> On 11/8/18 11:49 AM, Liu, Yi L wrote:
> > Hi,
> >
> >> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >> Sent: Thursday, November 8, 2018 10:17 AM
> >> Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit
> >> invalidation descriptor support
> >>
> >> Hi Yi,
> >>
> >> On 11/7/18 2:07 PM, Liu, Yi L wrote:
> >>> Hi Baolu,
> >>>
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
> >>> [...]
> >>>
> ---
> drivers/iommu/dmar.c| 83
> +++--
> drivers/iommu/intel-svm.c | 76
> --
> drivers/iommu/intel_irq_remapping.c | 6 ++-
> include/linux/intel-iommu.h | 9 +++-
> 4 files changed, 115 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index
> d9c748b6f9e4..ec10427b98ac 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1160,6 +1160,7 @@ static int qi_check_fault(struct
> intel_iommu *iommu, int
> index)
> int head, tail;
> struct q_inval *qi = iommu->qi;
> int wait_index = (index + 1) % QI_LENGTH;
> +int shift = qi_shift(iommu);
>
> if (qi->desc_status[wait_index] == QI_ABORT)
> return -EAGAIN;
> @@ -1173,13 +1174,15 @@ static int qi_check_fault(struct
> intel_iommu *iommu, int index)
> */
> if (fault & DMA_FSTS_IQE) {
> head = readl(iommu->reg + DMAR_IQH_REG);
> -if ((head >> DMAR_IQ_SHIFT) == index) {
> +if ((head >> shift) == index) {
> +struct qi_desc *desc = qi->desc + head;
> +
> pr_err("VT-d detected invalid
> descriptor: "
> "low=%llx, high=%llx\n",
> -(unsigned long long)qi->desc[index].low,
> -(unsigned long
> long)qi->desc[index].high);
> -memcpy(&qi->desc[index], &qi->desc[wait_index],
> -sizeof(struct qi_desc));
> +(unsigned long long)desc->qw0,
> +(unsigned long long)desc->qw1);
> >>> Still missing qw2 and qw3. May make the print differ based on if
> >>> smts is
> >> configed.
> >> qw2 and qw3 are reserved from software point of view. We don't
> >> need to print it for information.
> > But for Scalable mode, it should be valid?
> No. It's reserved for software.
> >>> No, I don’t think so. PRQ response would also be queued to hardware
> >>> by QI. For such QI descriptors, the high bits are not reserved.
> >>>
> >>
> >> Do you mean the private data fields of a page request descriptor or a
> >> page group response descriptor? Those fields contains software
> >> defined private data (might a kernel pointer?). We should avoid
> >> leaking such information in the generic kernel message for security
> >> consideration.
> >> Or anything I missed?
> >
> > yes, I'm not sure what kind of data it may be in the private data
> > field. From software point of view, it may be helpful to show the full
> > content of the QI descriptor for error triage. Personally, I'm fine if you
> > keep it on
> this point.
> >
>
> Okay, thanks.
>
> I think I need to put some comments there so that people could understand my
> consideration.
yeah, that would be helpful. :-)
Regards,
Yi Liu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor support
Hi,
On 11/8/18 3:20 PM, Liu, Yi L wrote:
Hi,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Thursday, November 8, 2018 2:14 PM
Hi,
On 11/8/18 1:45 PM, Liu, Yi L wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Thursday, November 8, 2018 1:25 PM
Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation
descriptor support
Hi,
On 11/8/18 11:49 AM, Liu, Yi L wrote:
Hi,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Thursday, November 8, 2018 10:17 AM
Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation
descriptor support
Hi Yi,
On 11/7/18 2:07 PM, Liu, Yi L wrote:
Hi Baolu,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, November 5, 2018 1:32 PM
[...]
---
drivers/iommu/dmar.c| 83 +++--
drivers/iommu/intel-svm.c | 76 --
drivers/iommu/intel_irq_remapping.c | 6 ++-
include/linux/intel-iommu.h | 9 +++-
4 files changed, 115 insertions(+), 59 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index
d9c748b6f9e4..ec10427b98ac 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1160,6 +1160,7 @@ static int qi_check_fault(struct
intel_iommu *iommu, int
index)
int head, tail;
struct q_inval *qi = iommu->qi;
int wait_index = (index + 1) % QI_LENGTH;
+ int shift = qi_shift(iommu);
if (qi->desc_status[wait_index] == QI_ABORT)
return -EAGAIN;
@@ -1173,13 +1174,15 @@ static int qi_check_fault(struct
intel_iommu *iommu, int index)
*/
if (fault & DMA_FSTS_IQE) {
head = readl(iommu->reg + DMAR_IQH_REG);
- if ((head >> DMAR_IQ_SHIFT) == index) {
+ if ((head >> shift) == index) {
+ struct qi_desc *desc = qi->desc + head;
+
pr_err("VT-d detected invalid descriptor: "
"low=%llx, high=%llx\n",
- (unsigned long long)qi->desc[index].low,
- (unsigned long long)qi->desc[index].high);
- memcpy(&qi->desc[index], &qi->desc[wait_index],
- sizeof(struct qi_desc));
+ (unsigned long long)desc->qw0,
+ (unsigned long long)desc->qw1);
Still missing qw2 and qw3. May make the print differ based on if smts is
configed.
qw2 and qw3 are reserved from software point of view. We don't need
to print it for information.
But for Scalable mode, it should be valid?
No. It's reserved for software.
No, I don’t think so. PRQ response would also be queued to hardware by
QI. For such QI descriptors, the high bits are not reserved.
Do you mean the private data fields of a page request descriptor or a page group
response descriptor? Those fields contains software defined private data (might
a
kernel pointer?). We should avoid leaking such information in the generic kernel
message for security consideration.
Or anything I missed?
yes, I'm not sure what kind of data it may be in the private data field. From
software
point of view, it may be helpful to show the full content of the QI descriptor
for error
triage. Personally, I'm fine if you keep it on this point.
Okay, thanks.
I think I need to put some comments there so that people could
understand my consideration.
Best regards,
Lu Baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 4.18 33/34] x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Christoph Hellwig
commit 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 upstream.
We already build the swiotlb code for 32-bit kernels with PAE support,
but the code to actually use swiotlb has only been enabled for 64-bit
kernels for an unknown reason.
Before Linux v4.18 we paper over this fact because the networking code,
the SCSI layer and some random block drivers implemented their own
bounce buffering scheme.
[ mingo: Changelog fixes. ]
Fixes: 21e07dba9fb1 ("scsi: reduce use of block bounce buffers")
Fixes: ab74cfebafa3 ("net: remove the PCI_DMA_BUS_IS_PHYS check in
illegal_highdma")
Reported-by: Matthew Whitehead
Signed-off-by: Christoph Hellwig
Signed-off-by: Thomas Gleixner
Tested-by: Matthew Whitehead
Cc: konrad.w...@oracle.com
Cc: iommu@lists.linux-foundation.org
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20181014075208.2715-1-...@lst.de
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/pci-swiotlb.c |2 --
1 file changed, 2 deletions(-)
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -42,10 +42,8 @@ IOMMU_INIT_FINISH(pci_swiotlb_detect_ove
int __init pci_swiotlb_detect_4gb(void)
{
/* don't initialize swiotlb if iommu=off (no_iommu=1) */
-#ifdef CONFIG_X86_64
if (!no_iommu && max_possible_pfn > MAX_DMA32_PFN)
swiotlb = 1;
-#endif
/*
* If SME is active then swiotlb will be set to 1 so that bounce
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 2/6] drivers core: Add I/O ASID allocator
On 07/11/2018 04:53, Lu Baolu wrote:
> Hi,
>
> On 10/20/18 2:11 AM, Jean-Philippe Brucker wrote:
>> +static inline void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid)
>> +{
>> +return -ESRCH;
>
> return NULL;
I'll fix it, thanks
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3
Hi, On 06/11/2018 16:25, j...@8bytes.org wrote: > 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 maintainable solution. I'd like this > to be a two-level approach, where the aux-domains are sub-domains of a > primary domain (naming is still to-be-improved): > > > struct iommu_domain *domain; > > domain = iommu_alloc_aux_domain(); > > iommu_attach_device(pdev, domain); /* Fails if device has not > support for this > domain-type */ I'm still not sure how this should interact with MSI on Arm. On x86 the MSI doorbell is a reserved IOVA region in the IOMMU, but for Arm it's a MMIO register in a separate IRQ chip, upstream of the SMMU. From the SMMU point of view, MSI is a normal DMA without PASID, and the corresponding IOMMU mapping must be present. SMMU mappings for the MSI doorbell are created by the IRQ driver, when the device driver requests an IRQ. Roughly speaking it goes like: request_irq() irq_chip_compose_msi_msg() iommu_dma_map_msi_msg() iommu_map(iommu_get_domain_for_dev(dev), ...) Currently for "normal" device drivers, this will create the MSI mapping on the default_domain (which is created before the drivers' probe()). Device drivers that attach an unmanaged domain *and* use MSIs - only VFIO so far - check if the MSI needs to be mapped, and then call iommu_get_msi_cookie() before requesting IRQs. With my previous SVA proposals the default_domain was used for SVA, so we didn't need any change. But now, depending on the order between the IRQ request and this attach(), iommu_get_domain_for_dev() will return either default_domain or the new domain. (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 attached to two domains at the same time. (2) Another solution is to enforce an order between request_irq() and iommu_attach_device() for all device drivers that intend to use SVA, and have them do the MSI mapping themselves between attaching the domain and requesting IRQs. I don't really like either but to make things easier for device drivers, I would go with option (1). Thanks, Jean > > /* Bind a process address space to the aux-domain */ > sva_handle = iommu_sva_bind_mm(domain, current, ...); > pasid = iommu_sva_get_pasid(sva_handle); > > mdev_handle = iommu_mdev_alloc_domain(domain); > iommu_mdev_map(mdev_handle, ...); > iommu_mdev_unmap(mdev_handle, ...); > > /* Do more work */ > > iommu_sva_unbind_mm(sva_handle); > > iommu_mdev_free_domain(mdev_handle); > > iommu_detach_device(domain, pdev); > > > Regards, > > Joerg > ___ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/dma: Use NUMA aware memory allocations in __iommu_dma_alloc_pages()
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Originally-from: Ganapatrao Kulkarni
Signed-off-by: John Garry
---
This patch was originally posted by Ganapatrao in [1] *.
However, after initial review, it was never reposted (due to lack of
cycles, I think). In addition, the functionality in its sibling patches
were merged through patches, as mentioned in [2]; this also refers to a
discussion on device local allocations vs CPU local allocations for DMA
pool, and which is better [3].
However, as mentioned in [3], dma_alloc_coherent() uses the locality
information from the device - as in direct DMA - so this patch is just
applying this same policy.
[1] https://lore.kernel.org/patchwork/patch/833004/
[2] https://lkml.org/lkml/2018/8/22/391
[3] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1692998.html
* Authorship on this updated patch may need to be fixed - I add not want to
add Ganapatrao's SOB without permission.
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d1b0475..ada00bc 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -449,20 +449,17 @@ static void __iommu_dma_free_pages(struct page **pages,
int count)
kvfree(pages);
}
-static struct page **__iommu_dma_alloc_pages(unsigned int count,
- unsigned long order_mask, gfp_t gfp)
+static struct page **__iommu_dma_alloc_pages(struct device *dev,
+ unsigned int count, unsigned long order_mask, gfp_t gfp)
{
struct page **pages;
- unsigned int i = 0, array_size = count * sizeof(*pages);
+ unsigned int i = 0, nid = dev_to_node(dev);
order_mask &= (2U << MAX_ORDER) - 1;
if (!order_mask)
return NULL;
- if (array_size <= PAGE_SIZE)
- pages = kzalloc(array_size, GFP_KERNEL);
- else
- pages = vzalloc(array_size);
+ pages = kvzalloc_node(count * sizeof(*pages), GFP_KERNEL, nid);
if (!pages)
return NULL;
@@ -483,8 +480,10 @@ static struct page **__iommu_dma_alloc_pages(unsigned int
count,
unsigned int order = __fls(order_mask);
order_size = 1U << order;
- page = alloc_pages((order_mask - order_size) ?
- gfp | __GFP_NORETRY : gfp, order);
+ page = alloc_pages_node(nid,
+ (order_mask - order_size) ?
+ gfp | __GFP_NORETRY : gfp,
+ order);
if (!page)
continue;
if (!order)
@@ -569,7 +568,8 @@ struct page **iommu_dma_alloc(struct device *dev, size_t
size, gfp_t gfp,
alloc_sizes = min_size;
count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- pages = __iommu_dma_alloc_pages(count, alloc_sizes >> PAGE_SHIFT, gfp);
+ pages = __iommu_dma_alloc_pages(dev, count, alloc_sizes >> PAGE_SHIFT,
+ gfp);
if (!pages)
return NULL;
--
1.9.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Patch "x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels" has been added to the 4.18-stable tree
This is a note to let you know that I've just added the patch titled
x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
to the 4.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-swiotlb-enable-swiotlb-for-4gig-ram-on-32-bit-kernels.patch
and it can be found in the queue-4.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Sun, 14 Oct 2018 09:52:08 +0200
Subject: x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
From: Christoph Hellwig
commit 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 upstream.
We already build the swiotlb code for 32-bit kernels with PAE support,
but the code to actually use swiotlb has only been enabled for 64-bit
kernels for an unknown reason.
Before Linux v4.18 we paper over this fact because the networking code,
the SCSI layer and some random block drivers implemented their own
bounce buffering scheme.
[ mingo: Changelog fixes. ]
Fixes: 21e07dba9fb1 ("scsi: reduce use of block bounce buffers")
Fixes: ab74cfebafa3 ("net: remove the PCI_DMA_BUS_IS_PHYS check in
illegal_highdma")
Reported-by: Matthew Whitehead
Signed-off-by: Christoph Hellwig
Signed-off-by: Thomas Gleixner
Tested-by: Matthew Whitehead
Cc: konrad.w...@oracle.com
Cc: iommu@lists.linux-foundation.org
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20181014075208.2715-1-...@lst.de
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/pci-swiotlb.c |2 --
1 file changed, 2 deletions(-)
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -42,10 +42,8 @@ IOMMU_INIT_FINISH(pci_swiotlb_detect_ove
int __init pci_swiotlb_detect_4gb(void)
{
/* don't initialize swiotlb if iommu=off (no_iommu=1) */
-#ifdef CONFIG_X86_64
if (!no_iommu && max_possible_pfn > MAX_DMA32_PFN)
swiotlb = 1;
-#endif
/*
* If SME is active then swiotlb will be set to 1 so that bounce
Patches currently in stable-queue which might be from h...@lst.de are
queue-4.18/block-don-t-deal-with-discard-limit-in-blkdev_issue_discard.patch
queue-4.18/x86-swiotlb-enable-swiotlb-for-4gig-ram-on-32-bit-kernels.patch
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 5/7] iommu: Add virtio-iommu driver
On 08/11/2018 14:51, Auger Eric wrote:
>>> +/*
>>> + * viommu_replay_mappings - re-send MAP requests
>>> + *
>>> + * When reattaching a domain that was previously detached from all
>>> endpoints,
>>> + * mappings were deleted from the device. Re-create the mappings available
>>> in
>>> + * the internal tree.
>>> + */
>>> +static int viommu_replay_mappings(struct viommu_domain *vdomain)
>>> +{
>>> + int ret;
> ret needs to be initialized here. Otherwise this can lead to a crash in
> viommu_add_device.
I actually hit this one while testing the other day :) Fixed in next version
Thanks,
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 6/7] iommu/virtio: Add probe request
On 08/11/2018 14:48, Auger Eric wrote:
>> +struct virtio_iommu_probe_property {
>> +__le16 type;
>> +__le16 length;
> the value[] field has disappeared but still is documented in the v0.8 spec.
Good catch. I removed value[] when reworking the
virtio_iommu_probe_resv_mem definition, because embedding a struct with
a flexible array into another violates the C99 standard, even though GCC
accepts it.
I'll remove it from the spec as well, but I probably won't publish a new
version for this change alone. The virtio spec itself has similar uses
of flexible arrays, that are given for explanation but aren't valid C
(and those wouldn't even compile).
Thanks,
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 5/7] iommu: Add virtio-iommu driver
Hi Jean-Philippe,
On 10/12/18 6:35 PM, Michael S. Tsirkin wrote:
> On Fri, Oct 12, 2018 at 03:59:15PM +0100, Jean-Philippe Brucker wrote:
>> The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
>> requests such as map/unmap over virtio transport without emulating page
>> tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
>> requests.
>>
>> The bulk of the code transforms calls coming from the IOMMU API into
>> corresponding virtio requests. Mappings are kept in an interval tree
>> instead of page tables.
>>
>> Signed-off-by: Jean-Philippe Brucker
>> ---
>> MAINTAINERS | 7 +
>> drivers/iommu/Kconfig | 11 +
>> drivers/iommu/Makefile| 1 +
>> drivers/iommu/virtio-iommu.c | 938 ++
>> include/uapi/linux/virtio_ids.h | 1 +
>> include/uapi/linux/virtio_iommu.h | 101
>> 6 files changed, 1059 insertions(+)
>> create mode 100644 drivers/iommu/virtio-iommu.c
>> create mode 100644 include/uapi/linux/virtio_iommu.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 48a65c3a4189..f02fa65f47e2 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -15599,6 +15599,13 @@ S: Maintained
>> F: drivers/virtio/virtio_input.c
>> F: include/uapi/linux/virtio_input.h
>>
>> +VIRTIO IOMMU DRIVER
>> +M: Jean-Philippe Brucker
>> +L: virtualizat...@lists.linux-foundation.org
>> +S: Maintained
>> +F: drivers/iommu/virtio-iommu.c
>> +F: include/uapi/linux/virtio_iommu.h
>> +
>> VIRTUAL BOX GUEST DEVICE DRIVER
>> M: Hans de Goede
>> M: Arnd Bergmann
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index c60395b7470f..2dc016dc2b92 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -414,4 +414,15 @@ config QCOM_IOMMU
>> help
>>Support for IOMMU on certain Qualcomm SoCs.
>>
>> +config VIRTIO_IOMMU
>> +bool "Virtio IOMMU driver"
>> +depends on VIRTIO=y
>> +select IOMMU_API
>> +select INTERVAL_TREE
>> +select ARM_DMA_USE_IOMMU if ARM
>> +help
>> + Para-virtualised IOMMU driver with virtio.
>> +
>> + Say Y here if you intend to run this kernel as a guest.
>> +
>> endif # IOMMU_SUPPORT
>> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
>> index ab5eba6edf82..4cd643408e49 100644
>> --- a/drivers/iommu/Makefile
>> +++ b/drivers/iommu/Makefile
>> @@ -31,3 +31,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>> obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>> obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
>> obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
>> +obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
>> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
>> new file mode 100644
>> index ..9fb38cd3b727
>> --- /dev/null
>> +++ b/drivers/iommu/virtio-iommu.c
>> @@ -0,0 +1,938 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Virtio driver for the paravirtualized IOMMU
>> + *
>> + * Copyright (C) 2018 Arm Limited
>> + */
>> +
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#define MSI_IOVA_BASE 0x800
>> +#define MSI_IOVA_LENGTH 0x10
>> +
>> +#define VIOMMU_REQUEST_VQ 0
>> +#define VIOMMU_NR_VQS 1
>> +
>> +/*
>> + * During development, it is convenient to time out rather than wait
>> + * indefinitely in atomic context when a device misbehaves and a request
>> doesn't
>> + * return. In production however, some requests shouldn't return until they
>> are
>> + * successful.
>> + */
>> +#ifdef DEBUG
>> +#define VIOMMU_REQUEST_TIMEOUT 1 /* 10s */
>> +#endif
>> +
>> +struct viommu_dev {
>> +struct iommu_device iommu;
>> +struct device *dev;
>> +struct virtio_device*vdev;
>> +
>> +struct ida domain_ids;
>> +
>> +struct virtqueue*vqs[VIOMMU_NR_VQS];
>> +spinlock_t request_lock;
>> +struct list_headrequests;
>> +
>> +/* Device configuration */
>> +struct iommu_domain_geometrygeometry;
>> +u64 pgsize_bitmap;
>> +u8 domain_bits;
>> +};
>> +
>> +struct viommu_mapping {
>> +phys_addr_t paddr;
>> +struct interval_tree_node iova;
>> +u32 flags;
>> +};
>> +
>> +struct viommu_domain {
>> +struct iommu_domain domain;
>> +struct viommu_dev *viommu;
>> +struct mutexmutex;
>> +unsigned intid;
>> +
>> +spinlock_t mappings_lock;
>> +struct rb_root_cac
Re: [PATCH v3 6/7] iommu/virtio: Add probe request
Hi Jean-Philippe,
On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
> When the device offers the probe feature, send a probe request for each
> device managed by the IOMMU. Extract RESV_MEM information. When we
> encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
> This will tell other subsystems that there is no need to map the MSI
> doorbell in the virtio-iommu, because MSIs bypass it.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/iommu/virtio-iommu.c | 147 --
> include/uapi/linux/virtio_iommu.h | 39
> 2 files changed, 180 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 9fb38cd3b727..8eaf66770469 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -56,6 +56,7 @@ struct viommu_dev {
> struct iommu_domain_geometrygeometry;
> u64 pgsize_bitmap;
> u8 domain_bits;
> + u32 probe_size;
> };
>
> struct viommu_mapping {
> @@ -77,8 +78,10 @@ struct viommu_domain {
> };
>
> struct viommu_endpoint {
> + struct device *dev;
> struct viommu_dev *viommu;
> struct viommu_domain*vdomain;
> + struct list_headresv_regions;
> };
>
> struct viommu_request {
> @@ -129,6 +132,9 @@ static off_t viommu_get_req_offset(struct viommu_dev
> *viommu,
> {
> size_t tail_size = sizeof(struct virtio_iommu_req_tail);
>
> + if (req->type == VIRTIO_IOMMU_T_PROBE)
> + return len - viommu->probe_size - tail_size;
> +
> return len - tail_size;
> }
>
> @@ -414,6 +420,101 @@ static int viommu_replay_mappings(struct viommu_domain
> *vdomain)
> return ret;
> }
>
> +static int viommu_add_resv_mem(struct viommu_endpoint *vdev,
> +struct virtio_iommu_probe_resv_mem *mem,
> +size_t len)
> +{
> + struct iommu_resv_region *region = NULL;
> + unsigned long prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> +
> + u64 start = le64_to_cpu(mem->start);
> + u64 end = le64_to_cpu(mem->end);
> + size_t size = end - start + 1;
> +
> + if (len < sizeof(*mem))
> + return -EINVAL;
> +
> + switch (mem->subtype) {
> + default:
> + dev_warn(vdev->dev, "unknown resv mem subtype 0x%x\n",
> + mem->subtype);
> + /* Fall-through */
> + case VIRTIO_IOMMU_RESV_MEM_T_RESERVED:
> + region = iommu_alloc_resv_region(start, size, 0,
> + IOMMU_RESV_RESERVED);
> + break;
> + case VIRTIO_IOMMU_RESV_MEM_T_MSI:
> + region = iommu_alloc_resv_region(start, size, prot,
> + IOMMU_RESV_MSI);
> + break;
> + }
> +
> + list_add(&vdev->resv_regions, ®ion->list);
> + return 0;
> +}
> +
> +static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device
> *dev)
> +{
> + int ret;
> + u16 type, len;
> + size_t cur = 0;
> + size_t probe_len;
> + struct virtio_iommu_req_probe *probe;
> + struct virtio_iommu_probe_property *prop;
> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> + struct viommu_endpoint *vdev = fwspec->iommu_priv;
> +
> + if (!fwspec->num_ids)
> + return -EINVAL;
> +
> + probe_len = sizeof(*probe) + viommu->probe_size +
> + sizeof(struct virtio_iommu_req_tail);
> + probe = kzalloc(probe_len, GFP_KERNEL);
> + if (!probe)
> + return -ENOMEM;
> +
> + probe->head.type = VIRTIO_IOMMU_T_PROBE;
> + /*
> + * For now, assume that properties of an endpoint that outputs multiple
> + * IDs are consistent. Only probe the first one.
> + */
> + probe->endpoint = cpu_to_le32(fwspec->ids[0]);
> +
> + ret = viommu_send_req_sync(viommu, probe, probe_len);
> + if (ret)
> + goto out_free;
> +
> + prop = (void *)probe->properties;
> + type = le16_to_cpu(prop->type) & VIRTIO_IOMMU_PROBE_T_MASK;
> +
> + while (type != VIRTIO_IOMMU_PROBE_T_NONE &&
> +cur < viommu->probe_size) {
> + len = le16_to_cpu(prop->length) + sizeof(*prop);
> +
> + switch (type) {
> + case VIRTIO_IOMMU_PROBE_T_RESV_MEM:
> + ret = viommu_add_resv_mem(vdev, (void *)prop, len);
> + break;
> + default:
> + dev_err(dev, "unknown viommu prop 0x%x\n", type);
> + }
> +
> + if (ret)
> + dev_err(dev, "failed to parse viommu prop 0x%x\n",
> type);
> +
> + cur += len;
> + if (cur >= viommu->probe_size)
> + break;
> +
> + prop = (void *)probe->properties
Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
On Thu, Nov 08, 2018 at 02:03:33PM +, Fabrizio Castro wrote: > Joerg, does this patch look ok to you? Applied both patches, thanks Fabrizio. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH -next] iommu/amd: Add missed 'tag' to error msg in iommu_print_event
On Thu, Nov 08, 2018 at 11:57:33AM +, YueHaibing wrote: > - dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x > pasid=0x%05x address=0x%016llx flags=0x%04x]\n", > + dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x > pasid=0x%05x address=0x%016llx flags=0x%04x tag=0x%08x]\n", Changed the %08x to %03x, which is enough for a 10-bit value, and applied it to x86/amd. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
Thank you Simon for getting back to me. Joerg, does this patch look ok to you? Thanks, Fab > Subject: Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > On Thu, Nov 08, 2018 at 11:23:58AM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this one is also for Joerg. > > > Thanks, > > Fab > > > > > From: Fabrizio Castro > > > Sent: 17 August 2018 15:31 > > > Subject: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > > > > > Document RZ/G2M (R8A774A1) SoC bindings. > > > > > > Signed-off-by: Fabrizio Castro > > > Reviewed-by: Biju Das > > > --- > > > This patch applies on top of next-20180817 > > > > > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > index ffadb7c..68446dd 100644 > > > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > @@ -13,6 +13,7 @@ Required Properties: > > > - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. > > > - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. > > > - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. > > > +- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. > > > - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. > > > - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. > > > - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. > > > -- > > > 2.7.4 > > > > > > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > > Buckinghamshire, SL8 5FH, UK. Registered in England > & Wales under Registered No. 04586709. > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
Thank you Simon for getting back to me.
Joerg, does this patch look ok to you?
Thanks,
Fab
> Subject: Re: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
>
> Hi Fabrizio,
>
> I believe this one is for Joerg.
>
> On Thu, Nov 08, 2018 at 11:22:55AM +, Fabrizio Castro wrote:
> > Dear All,
> >
> > Who is the best person to take this patch?
> >
> > Thanks,
> > Fab
> >
> > > From: Fabrizio Castro
> > > Sent: 23 August 2018 16:33
> > > Subject: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
> > >
> > > Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
> > >
> > > Signed-off-by: Fabrizio Castro
> > > Reviewed-by: Biju Das
> > > ---
> > > v1-v2:
> > > * taken out IOMMU_OF_DECLARE
> > >
> > > drivers/iommu/ipmmu-vmsa.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > > index 51af2c5..331562f 100644
> > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> > > }
> > >
> > > static const struct soc_device_attribute soc_rcar_gen3[] = {
> > > +{ .soc_id = "r8a774a1", },
> > > { .soc_id = "r8a7795", },
> > > { .soc_id = "r8a7796", },
> > > { .soc_id = "r8a77965", },
> > > @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> > > .compatible = "renesas,ipmmu-vmsa",
> > > .data = &ipmmu_features_default,
> > > }, {
> > > +.compatible = "renesas,ipmmu-r8a774a1",
> > > +.data = &ipmmu_features_rcar_gen3,
> > > +}, {
> > > .compatible = "renesas,ipmmu-r8a7795",
> > > .data = &ipmmu_features_rcar_gen3,
> > > }, {
> > > --
> > > 2.7.4
> >
> >
> >
> >
> > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
> > Buckinghamshire, SL8 5FH, UK. Registered in England
> & Wales under Registered No. 04586709.
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: iommu/io-pgtable-arm-v7s: About pagetable 33bit PA
On 08/11/2018 07:31, Yong Wu wrote:
Hi Robin,
After the commit ad67f5a6545f ("arm64: replace ZONE_DMA with
ZONE_DMA32"), we don't have ZONE_DMA in aarch64, but
__arm_v7s_alloc_table[1] use the GFP_DMA to expect the physical address
of pagetable should be 32bit.
Right now we meet a issue that the lvl1 pagetable PA is 0x1_3ab6_ in
the 4GB broad. then the IOMMU initialize failed.(This issue can be fixed
if we revert ad67f5a6545f.)
But that shouldn't actually be failing on MTK platforms anyway, right,
since your IOMMU is still capable of addressing that? Seems like we
overlooked that check in __arm_v7s_alloc_table(), where the conversion
by casting will want updating to something like
"iopte_to_paddr(paddr_to_iopte(...))" in patch #4 of your series.
I planed to add GFP_DMA32 for pagetable allocation. the level1 was
ok but level2 was failed. It looks that slab don't like GFP_DMA32[2].
this is the warning log:
=
Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x488020 (GFP_ATOMIC|
__GFP_ZERO). Fix your code!
=
I don't know why slab don't allow GFP_DMA32, the gfp flags seems only
be bypassed to alloc_page. Is it possible that let slab allow GFP_DMA32
for aarch64?
I had a bit of a look into it some time ago, and I don't recall seeing
any obvious reason that the kmem_cache API couldn't support ZONE_DMA32
in general (either via a separate SLAB_CACHE_DMA32, or just overloading
SLAB_CACHE_DMA depending on which of CONFIG_ZONE_DMA/CONFIG_ZONE_DMA32
are enabled) - I guess that's just never been implemented since nobody
needed it before.
Robin.
We notice that this has been discussed[3]. but if we use alloc_page for
the level2 pagetable, It may waste lots of memory.
Any suggestion is appreciated.
Reported-by: Nicolas Boichat
[1]
https://elixir.bootlin.com/linux/v4.20-rc1/source/drivers/iommu/io-pgtable-arm-v7s.c#L200
[2] https://elixir.bootlin.com/linux/v4.20-rc1/source/mm/internal.h#L37
[3] https://patchwork.kernel.org/patch/10474289/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
On Thu, Nov 08, 2018 at 11:23:58AM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this one is also for Joerg. > Thanks, > Fab > > > From: Fabrizio Castro > > Sent: 17 August 2018 15:31 > > Subject: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > > > Document RZ/G2M (R8A774A1) SoC bindings. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Biju Das > > --- > > This patch applies on top of next-20180817 > > > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > index ffadb7c..68446dd 100644 > > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > @@ -13,6 +13,7 @@ Required Properties: > > - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. > > - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. > > - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. > > +- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. > > - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. > > - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. > > - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. > > -- > > 2.7.4 > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered > No. 04586709. > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
On Fri, Aug 17, 2018 at 03:31:05PM +0100, Fabrizio Castro wrote: > Document RZ/G2M (R8A774A1) SoC bindings. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > This patch applies on top of next-20180817 Reviewed-by: Simon Horman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
On Thu, Aug 23, 2018 at 04:33:04PM +0100, Fabrizio Castro wrote:
> Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Simon Horman
> ---
> v1-v2:
> * taken out IOMMU_OF_DECLARE
>
> drivers/iommu/ipmmu-vmsa.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 51af2c5..331562f 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> }
>
> static const struct soc_device_attribute soc_rcar_gen3[] = {
> + { .soc_id = "r8a774a1", },
> { .soc_id = "r8a7795", },
> { .soc_id = "r8a7796", },
> { .soc_id = "r8a77965", },
> @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> .compatible = "renesas,ipmmu-vmsa",
> .data = &ipmmu_features_default,
> }, {
> + .compatible = "renesas,ipmmu-r8a774a1",
> + .data = &ipmmu_features_rcar_gen3,
> + }, {
> .compatible = "renesas,ipmmu-r8a7795",
> .data = &ipmmu_features_rcar_gen3,
> }, {
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
Hi Fabrizio,
I believe this one is for Joerg.
On Thu, Nov 08, 2018 at 11:22:55AM +, Fabrizio Castro wrote:
> Dear All,
>
> Who is the best person to take this patch?
>
> Thanks,
> Fab
>
> > From: Fabrizio Castro
> > Sent: 23 August 2018 16:33
> > Subject: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
> >
> > Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Biju Das
> > ---
> > v1-v2:
> > * taken out IOMMU_OF_DECLARE
> >
> > drivers/iommu/ipmmu-vmsa.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > index 51af2c5..331562f 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> > }
> >
> > static const struct soc_device_attribute soc_rcar_gen3[] = {
> > +{ .soc_id = "r8a774a1", },
> > { .soc_id = "r8a7795", },
> > { .soc_id = "r8a7796", },
> > { .soc_id = "r8a77965", },
> > @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> > .compatible = "renesas,ipmmu-vmsa",
> > .data = &ipmmu_features_default,
> > }, {
> > +.compatible = "renesas,ipmmu-r8a774a1",
> > +.data = &ipmmu_features_rcar_gen3,
> > +}, {
> > .compatible = "renesas,ipmmu-r8a7795",
> > .data = &ipmmu_features_rcar_gen3,
> > }, {
> > --
> > 2.7.4
>
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
> Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
> No. 04586709.
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH -next] iommu/amd: Add missed 'tag' to error msg in iommu_print_event
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/iommu/amd_iommu.c: In function 'iommu_print_event':
drivers/iommu/amd_iommu.c:550:33: warning:
variable 'tag' set but not used [-Wunused-but-set-variable]
It was introduced in
e7f63ffc1bf1 ("iommu/amd: Update logging information for new event type")
seems just missed in the error message, add it as suggested by Joerg.
Signed-off-by: YueHaibing
---
drivers/iommu/amd_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 1167ff0..872b76e 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -622,9 +622,9 @@ static void iommu_print_event(struct amd_iommu *iommu, void
*__evt)
pasid = ((event[0] >> 16) & 0x)
| ((event[1] << 6) & 0xF);
tag = event[1] & 0x03FF;
- dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x
pasid=0x%05x address=0x%016llx flags=0x%04x]\n",
+ dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x
pasid=0x%05x address=0x%016llx flags=0x%04x tag=0x%08x]\n",
PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid),
- pasid, address, flags);
+ pasid, address, flags, tag);
break;
default:
dev_err(dev, "UNKNOWN event[0]=0x%08x event[1]=0x%08x
event[2]=0x%08x event[3]=0x%08x\n",
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC] iommu/vt-d: Group and domain relationship
Hey,
> On 8 Nov 2018, at 01:42, Lu Baolu wrote:
>
> Hi,
>
> On 11/8/18 1:55 AM, James Sewart wrote:
>> Hey,
>>> On 7 Nov 2018, at 02:10, Lu Baolu wrote:
>>>
>>> Hi,
>>>
>>> On 11/6/18 6:40 PM, James Sewart wrote:
Hey Lu,
Would you be able to go into more detail about the issues with
allowing IOMMU_DOMAIN_DMA to be allocated via domain_alloc?
>>>
>>> This door is closed because intel iommu driver does everything for
>>> IOMMU_DOMAIN_DMA: allocating a domain and setup the context entries
>>> for the domain.
>> As far as I can tell, attach_device in the intel driver will handle
>> cleaning up any old domain context mapping and ensure the new domain is
>> mapped with calls to dmar_remove_one_dev_info and domain_add_dev_info.
>
> That's only for domains of IOMMU_DOMAIN_UNMANAGED, right?
attach_device has logic for cleaning up domains that are allocated by the
intel driver.
old_domain = find_domain(dev);
if (old_domain) {
rcu_read_lock();
dmar_remove_one_dev_info(old_domain, dev);
rcu_read_unlock();
if (!domain_type_is_vm_or_si(old_domain) &&
list_empty(&old_domain->devices))
domain_exit(old_domain);
}
This is checking the type of the old domain only, freeing it if is not
attached to any devices. Looking at this now, maybe the solution would be
to distinguish between internally allocated dma domains and dma domains
allocated via the external api, so we avoid freeing a domain a driver has
reference to.
>>>
>>> Why do we want to open this door? Probably we want the generic iommu
>>> layer to handle these things (it's called default domain).
>> I’d like to allocate a domain and attach it to multiple devices in a
>> group/multiple groups so that they share address translation, but still
>> allow drivers for devices in those groups to use the dma_map_ops api.
>
> Just out of curiosity, why do you want to share a single domain across
> multiple groups? By default, the groups and DMA domains are normally
> 1-1 mapped, right?
Currently we see each device in a group with their own domain.
find_or_alloc_domain looks at dma aliases to determine who shares domains
whereas pci_device_group in the generic iommu code determines groups using
a few other checks. We have observed internally that devices under a pcie
switch will be put in the same group but they do not share a domain within
that group.
Getting every device within a group to share a domain would get us 90% of
the way to what we want. But we have some configurations where there exist
devices put in other groups that we want to share translations with.
>
>>> So we can't just open the door but not cleanup the things right?
>> A user of domain_alloc and attach_device is responsible for detaching a
>> domain if it is no longer needed and calling domain_free.
>
> Currently DMA API calls get_valid_domain_for_dev() to retrieve a DMA
> domain. If the domain has already been allocated, return directly.
> Otherwise, allocate and initialize a new one for the device. Let's call
> domains allocated by get_valid_domain_for_dev() as "A".
>
> If we open the door and allow another component to manage the DMA
> domains through domain iommu_domain_alloc/free(). Let's call domains
> allocated through iommu_domain_alloc() as "B".
>
> So how can we sync between A and B?
I’m not sure we need to sync them. Domain A would be replaced entirely for
a certain device with domain B by attach_device. As we saw above domain A
would be freed if there are no more devices attached to it. Domain B would
be managed by the user of the iommu api. If a device is detached from
domain B, the find_or_alloc_domain logic will take over once more and
allocate a fresh domain.
Cheers,
James.
>
> Need to go through the code to find out more.
>
> Best regards,
> Lu Baolu
>> Cheers,
>> James.
>>>
>>> I haven't spent time on details. So I cc'ed Jacob for corrections.
>>>
>>> Best regards,
>>> Lu Baolu
>>>
Cheers,
James.
On Fri, Nov 2, 2018 at 2:43 AM Lu Baolu wrote:
>
> Hi,
>
> On 10/30/18 10:18 PM, James Sewart via iommu wrote:
>> Hey,
>>
>> I’ve been investigating the relationship between iommu groups and domains
>> on our systems and have a few question. Why does the intel iommu code not
>> allow allocating IOMMU_DOMAIN_DMA? Returning NULL when given this domain
>> type has the side effect that the default_domain for an iommu group is
>> not
>> set, which, when using for e.g. dma_map_ops.map_page, means a domain is
>> allocated per device.
>
> Intel vt-d driver doesn't implement the default domain and allocates
> domain only on demanded. There are lots of things to do before we allow
> iommu API to allocate domains other than IOMMU_DOMAIN_UNMANAGED.
>
> B
RE: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
Dear All, Who is the best person to take this patch? Thanks, Fab > From: Fabrizio Castro > Sent: 17 August 2018 15:31 > Subject: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > Document RZ/G2M (R8A774A1) SoC bindings. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > This patch applies on top of next-20180817 > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > index ffadb7c..68446dd 100644 > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > @@ -13,6 +13,7 @@ Required Properties: > - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. > - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. > - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. > +- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. > - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. > - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. > - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
Dear All,
Who is the best person to take this patch?
Thanks,
Fab
> From: Fabrizio Castro
> Sent: 23 August 2018 16:33
> Subject: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
>
> Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
> ---
> v1-v2:
> * taken out IOMMU_OF_DECLARE
>
> drivers/iommu/ipmmu-vmsa.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 51af2c5..331562f 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> }
>
> static const struct soc_device_attribute soc_rcar_gen3[] = {
> +{ .soc_id = "r8a774a1", },
> { .soc_id = "r8a7795", },
> { .soc_id = "r8a7796", },
> { .soc_id = "r8a77965", },
> @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> .compatible = "renesas,ipmmu-vmsa",
> .data = &ipmmu_features_default,
> }, {
> +.compatible = "renesas,ipmmu-r8a774a1",
> +.data = &ipmmu_features_rcar_gen3,
> +}, {
> .compatible = "renesas,ipmmu-r8a7795",
> .data = &ipmmu_features_rcar_gen3,
> }, {
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH -next] iommu/amd: remove set but not used variable 'tag'
On 2018/11/8 17:32, Joerg Roedel wrote: > On Thu, Nov 08, 2018 at 06:12:40AM +, YueHaibing wrote: >> -tag = event[1] & 0x03FF; >> dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x >> pasid=0x%05x address=0x%016llx flags=0x%04x]\n", >> PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid), >> pasid, address, flags); > > This looks like tag was just missed in the error message. It is better > to add it there instead of removing it. Ok, will post a new patch. > > Regards, > > Joerg > > . > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH -next] iommu/amd: remove set but not used variable 'tag'
On Thu, Nov 08, 2018 at 06:12:40AM +, YueHaibing wrote: > - tag = event[1] & 0x03FF; > dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x > pasid=0x%05x address=0x%016llx flags=0x%04x]\n", > PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid), > pasid, address, flags); This looks like tag was just missed in the error message. It is better to add it there instead of removing it. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/vt-d: respect max guest address width in agaw
On Wed, Nov 07, 2018 at 02:12:25PM -0800, Jacob Pan wrote: > We have found some issues with this patch on some platforms. Please > disregard this patch. Patch dropped. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
