Re: use generic DMA mapping code in powerpc V4
On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote: > OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use > the dma_direct mapping routines) > > git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a > > git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b > > Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet > doesn't work. Are there any interesting messages in the boot log? Can you send me the dmesg? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dmaengine: fsl-edma: dma map slave device address
On 18-01-19, 12:06, Laurentiu Tudor wrote: > This mapping needs to be created in order for slave dma transfers > to work on systems with SMMU. The implementation mostly mimics the > one in pl330 dma driver, authored by Robin Murphy. Applied, thanks -- ~Vinod ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V2 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available
Hi Lan, Thank you for the patch! Yet something to improve: [auto build test ERROR on iommu/next] [also build test ERROR on v5.0-rc4 next-20190204] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/lantianyu1986-gmail-com/x86-Hyper-V-IOMMU-Add-Hyper-V-IOMMU-driver-to-support-x2apic-mode/20190204-132009 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: i386-randconfig-a3-02040849 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): arch/x86/kernel/cpu/mshyperv.c: In function 'ms_hyperv_init_platform': >> arch/x86/kernel/cpu/mshyperv.c:339:3: error: 'x2apic_phys' undeclared (first >> use in this function) x2apic_phys = 1; ^ arch/x86/kernel/cpu/mshyperv.c:339:3: note: each undeclared identifier is reported only once for each function it appears in vim +/x2apic_phys +339 arch/x86/kernel/cpu/mshyperv.c 331 332 /* 333 * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, 334 * set x2apic destination mode to physcial mode when x2apic is available 335 * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs 336 * have 8-bit APIC id. 337 */ 338 if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported()) > 339 x2apic_phys = 1; 340 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V2 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available
Hi Lan, Thank you for the patch! Yet something to improve: [auto build test ERROR on iommu/next] [also build test ERROR on v5.0-rc4 next-20190201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/lantianyu1986-gmail-com/x86-Hyper-V-IOMMU-Add-Hyper-V-IOMMU-driver-to-support-x2apic-mode/20190204-132009 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: x86_64-randconfig-x005-201905 (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): arch/x86//kernel/cpu/mshyperv.c: In function 'ms_hyperv_init_platform': >> arch/x86//kernel/cpu/mshyperv.c:339:3: error: 'x2apic_phys' undeclared >> (first use in this function); did you mean 'x2apic_mode'? x2apic_phys = 1; ^~~ x2apic_mode arch/x86//kernel/cpu/mshyperv.c:339:3: note: each undeclared identifier is reported only once for each function it appears in vim +339 arch/x86//kernel/cpu/mshyperv.c 331 332 /* 333 * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, 334 * set x2apic destination mode to physcial mode when x2apic is available 335 * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs 336 * have 8-bit APIC id. 337 */ 338 if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported()) > 339 x2apic_phys = 1; 340 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH V2 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available
From: lantianyu1...@gmail.com Sent: Saturday, February 2, 2019 5:15 AM > > Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, > set x2apic destination mode to physcial mode when x2apic is available > and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have > 8-bit APIC id. > > Signed-off-by: Lan Tianyu > --- > Change since v1: >- Remove redundant extern for x2apic_phys > --- > arch/x86/kernel/cpu/mshyperv.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > index e81a2db..4bd6d90 100644 > --- a/arch/x86/kernel/cpu/mshyperv.c > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -328,6 +328,16 @@ static void __init ms_hyperv_init_platform(void) > # ifdef CONFIG_SMP > smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu; > # endif > + > +/* > + * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, > + * set x2apic destination mode to physcial mode when x2apic is available > + * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs > + * have 8-bit APIC id. > + */ Per comment from Dan Carpenter on v1 of this patch, the above comment block should be indented one tab to line up with the "if" statement below. Michael > + if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported()) > + x2apic_phys = 1; > + > #endif > } > > -- > 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH V2 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
From: lantianyu1...@gmail.com Sent: Saturday,
February 2, 2019 5:15 AM
I have a couple more comments
>
> +config HYPERV_IOMMU
> + bool "Hyper-V IRQ Remapping Support"
> + depends on HYPERV
> + select IOMMU_API
> + help
> + Hyper-V stub IOMMU driver provides IRQ Remapping capability
> + to run Linux guest with X2APIC mode on Hyper-V.
> +
> +
I'm a little concerned about the terminology here. The comments and
commit messages for these patches all say that Hyper-V guests don't
have interrupt remapping support. And we don't really *need* interrupt
remapping support because all the interrupts that should be nicely spread
out across all vCPUs (i.e., the MSI interrupts for PCI pass-thru devices) are
handled via a hypercall in pci-hyperv.c, and not via the virtual IOAPIC. So
we have this stub IOMMU driver that doesn't actually do interrupt remapping.
It just prevents assigning the very small number of non-performance sensitive
IOAPIC interrupts to a CPU with an APIC ID above 255.
With that background, describing this feature as "Hyper-V IRQ Remapping
Support" seems incorrect, and similarly in the "help" description. Finding
good terminology for this situation is hard. But how about narrowing the
focus to x2APIC handling:
bool "Hyper-V x2APIC IRQ Handling"
...
help
Stub IOMMU driver to handle IRQs as to allow Hyper-V Linux
guests to run with x2APIC mode enabled
> +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs,
> + void *arg)
> +{
> + struct irq_alloc_info *info = arg;
> + struct irq_data *irq_data;
> + struct irq_desc *desc;
> + int ret = 0;
> +
> + if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> + return -EINVAL;
> +
> + ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + irq_data = irq_domain_get_irq_data(domain, virq);
> + if (!irq_data) {
> + irq_domain_free_irqs_common(domain, virq, nr_irqs);
> + return -EINVAL;
> + }
> +
> + irq_data->chip = &hyperv_ir_chip;
> +
> + /*
> + * IOAPIC entry pointer is saved in chip_data to allow
> + * hyperv_irq_remappng_activate()/hyperv_ir_set_affinity() to set
> + * vector and dest_apicid. cfg->vector and cfg->dest_apicid are
> + * ignorred when IRQ remapping is enabled. See ioapic_configure_entry().
> + */
> + irq_data->chip_data = info->ioapic_entry;
> +
> + /*
> + * Hypver-V IO APIC irq affinity should be in the scope of
> + * ioapic_max_cpumask because no irq remapping support.
> + */
> + desc = irq_data_to_desc(irq_data);
> + cpumask_and(desc->irq_common_data.affinity,
> + desc->irq_common_data.affinity,
> + &ioapic_max_cpumask);
The intent of this cpumask_and() call is to ensure that IOAPIC interrupts
are initially assigned to a CPU with APIC ID < 256. But do we know that
the initial value of desc->irq_common_data.affinity is such that the result
of the cpumask_and() will not be the empty set? My impression is that
these local IOAPIC interrupts are assigned an initial affinity mask with all
CPUs set, in which case this will work just fine. But I'm not sure if that
is guaranteed.
An alternative would be to set the affinity to ioapic_max_cpumask and
overwrite whatever might have been previously specified. But I don't know
if that's really better.
> +
> + return 0;
> +}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH V2 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
From: lantianyu1...@gmail.com Sent: Saturday,
February 2, 2019 5:15 AM
>
> +/*
> + * According 82093AA IO-APIC spec , IO APIC has a 24-entry Interrupt
> + * Redirection Table.
> + */
> +#define IOAPIC_REMAPPING_ENTRY 24
The other unstated assumption here is that Hyper-v guest VMs
have only a single IOAPIC, regardless of the size of the VM.
Perhaps that should be stated in the comment explaining why
there are 24 entries?
> +
> +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> +static struct irq_domain *ioapic_ir_domain;
> +
> +static int hyperv_ir_set_affinity(struct irq_data *data,
> + const struct cpumask *mask, bool force)
> +{
> + struct irq_data *parent = data->parent_data;
> + struct irq_cfg *cfg = irqd_cfg(data);
> + struct IO_APIC_route_entry *entry;
> + cpumask_t cpumask;
> + int ret;
> +
> + cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
> +
> + /* Return error If new irq affinity is out of ioapic_max_cpumask. */
> + if (!cpumask_empty(&cpumask))
> + return -EINVAL;
The above two cpumask functions can be combined in a single
call to cpumask_subset(). This has the nice property that determining
whether the cpus in "mask" are a subset of the cpus in "ioapic_max_cpumask"
is exactly what this code is trying to do. :-) And it gets rid of the local
cpumask variable and the associated compiler warnings about stack frame
size.
> +
> + ret = parent->chip->irq_set_affinity(parent, mask, force);
> + if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> + return ret;
> +
> + entry = data->chip_data;
> + entry->dest = cfg->dest_apicid;
> + entry->vector = cfg->vector;
> + send_cleanup_vector(cfg);
> +
> + return 0;
> +}
> +
> +static struct irq_chip hyperv_ir_chip = {
> + .name = "HYPERV-IR",
> + .irq_ack= apic_ack_irq,
> + .irq_set_affinity = hyperv_ir_set_affinity,
> +};
> +
> +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs,
> + void *arg)
> +{
> + struct irq_alloc_info *info = arg;
> + struct irq_data *irq_data;
> + struct irq_desc *desc;
> + int ret = 0;
> +
> + if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> + return -EINVAL;
> +
> + ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + irq_data = irq_domain_get_irq_data(domain, virq);
> + if (!irq_data) {
> + irq_domain_free_irqs_common(domain, virq, nr_irqs);
> + return -EINVAL;
> + }
> +
> + irq_data->chip = &hyperv_ir_chip;
> +
> + /*
> + * IOAPIC entry pointer is saved in chip_data to allow
> + * hyperv_irq_remappng_activate()/hyperv_ir_set_affinity() to set
> + * vector and dest_apicid. cfg->vector and cfg->dest_apicid are
> + * ignorred when IRQ remapping is enabled. See ioapic_configure_entry().
Spelling: "ignored".
I saw Vitaly previous comments, and I still don't understand this comment. :-(
Is IRQ remapping considered to be enabled by this IOMMU driver, such that
cfg->vector and cfg->dest_apicid are ignored? Or is the "when IRQ remapping
is enabled" a statement about some future enhancement?
> + */
> + irq_data->chip_data = info->ioapic_entry;
> +
> + /*
> + * Hypver-V IO APIC irq affinity should be in the scope of
> + * ioapic_max_cpumask because no irq remapping support.
> + */
> + desc = irq_data_to_desc(irq_data);
> + cpumask_and(desc->irq_common_data.affinity,
> + desc->irq_common_data.affinity,
> + &ioapic_max_cpumask);
> +
> + return 0;
> +}
> +
> +static void hyperv_irq_remapping_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + irq_domain_free_irqs_common(domain, virq, nr_irqs);
> +}
> +
> +static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> + struct irq_data *irq_data, bool reserve)
> +{
> + struct irq_cfg *cfg = irqd_cfg(irq_data);
> + struct IO_APIC_route_entry *entry = irq_data->chip_data;
> +
> + entry->dest = cfg->dest_apicid;
> + entry->vector = cfg->vector;
> +
> + return 0;
> +}
> +
> +static struct irq_domain_ops hyperv_ir_domain_ops = {
> + .alloc = hyperv_irq_remapping_alloc,
> + .free = hyperv_irq_remapping_free,
> + .activate = hyperv_irq_remappng_activate,
> +};
> +
> +static int __init hyperv_prepare_irq_remapping(void)
> +{
> + struct fwnode_handle *fn;
> + u32 apic_id;
> + int i;
> +
> + if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
The function hypervisor_is_type() exists for doing the above test.
See include/asm/hypervisor.h
> + !x2apic_supported())
> + return -ENODEV;
> +
> + fn =
Re: use generic DMA mapping code in powerpc V4
OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use the dma_direct mapping routines) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't work. -- Christian On 01 February 2019 at 5:54PM, Christian Zigotzky wrote: Hi Christoph, I will try it at the weekend. Thanks, Christian Sent from my iPhone On 1. Feb 2019, at 09:04, Christoph Hellwig wrote: On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote: Hi Christoph, I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6' today. Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't work. Oh. Can you try with just the next one and then two patches applied over the working setup? That is first: http://git.infradead.org/users/hch/misc.git/commitdiff/b50f42f0fe12965ead395c76bcb6a14f00cdf65b then also with: http://git.infradead.org/users/hch/misc.git/commitdiff/21fe52470a483afbb1726741118abef8602dde4d ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/ipmmu-vmsa: fix device reference leaks
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: linux-ker...@vger.kernel.org --- drivers/iommu/ipmmu-vmsa.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 7a4529c..cebf56d 100644 --- a/drivers/iommu/ipmmu-vmsa.c +++ b/drivers/iommu/ipmmu-vmsa.c @@ -756,6 +756,9 @@ static int ipmmu_init_platform_device(struct device *dev, fwspec->iommu_priv = platform_get_drvdata(ipmmu_pdev); + if (!fwspec->iommu_priv) + put_device(&ipmmu_pdev->dev); + return 0; } -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 6/9] iommu/dma-iommu.c: Convert to use vm_insert_range
Hi Joerg,
On Thu, Jan 31, 2019 at 8:38 AM Souptick Joarder wrote:
>
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
Can you please help to review this patch ?
> ---
> drivers/iommu/dma-iommu.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index d19f3d6..bdf14b87 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -620,17 +620,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t
> size, gfp_t gfp,
>
> int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct
> *vma)
> {
> - unsigned long uaddr = vma->vm_start;
> - unsigned int i, count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - int ret = -ENXIO;
> -
> - for (i = vma->vm_pgoff; i < count && uaddr < vma->vm_end; i++) {
> - ret = vm_insert_page(vma, uaddr, pages[i]);
> - if (ret)
> - break;
> - uaddr += PAGE_SIZE;
> - }
> - return ret;
> + return vm_insert_range(vma, pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
> }
>
> static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
> --
> 1.9.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
