Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size
On Thu, Apr 20, 2017 at 12:29:20PM -0500, Tom Lendacky wrote:
> Hmmm... and actually if cpu_has(X86_FEATURE_SME) is true then it's a
> given that extended_cpuid_level >= 0x801f. So this can be
> simplified to just:
>
> if (cpu_has(c, X86_FEATURE_SME)) {
> ... the rest of your suggestion (minus cpu_has()) ...
Cool, even better! :)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5] arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU
Catching up with these threads, so replying to a patch I already
applied.
On Tue, Mar 07, 2017 at 06:43:32PM +0100, Geert Uytterhoeven wrote:
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -584,20 +584,7 @@ static void *__iommu_alloc_attrs(struct device *dev,
> size_t size,
>*/
> gfp |= __GFP_ZERO;
>
> - if (gfpflags_allow_blocking(gfp)) {
> - struct page **pages;
> - pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, coherent);
> -
> - pages = iommu_dma_alloc(dev, iosize, gfp, attrs, ioprot,
> - handle, flush_page);
> - if (!pages)
> - return NULL;
> -
> - addr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
> - __builtin_return_address(0));
> - if (!addr)
> - iommu_dma_free(dev, pages, iosize, handle);
> - } else {
> + if (!gfpflags_allow_blocking(gfp)) {
> struct page *page;
> /*
>* In atomic context we can't remap anything, so we'll only
> @@ -621,6 +608,45 @@ static void *__iommu_alloc_attrs(struct device *dev,
> size_t size,
> __free_from_pool(addr, size);
> addr = NULL;
> }
> + } else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> + pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, coherent);
> + struct page *page;
> +
> + page = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
> + get_order(size), gfp);
> + if (!page)
> + return NULL;
> +
> + *handle = iommu_dma_map_page(dev, page, 0, iosize, ioprot);
> + if (iommu_dma_mapping_error(dev, *handle)) {
> + dma_release_from_contiguous(dev, page,
> + size >> PAGE_SHIFT);
> + return NULL;
> + }
> + if (!coherent)
> + __dma_flush_area(page_to_virt(page), iosize);
> +
> + addr = dma_common_contiguous_remap(page, size, VM_USERMAP,
> +prot,
> +__builtin_return_address(0));
Do we need to call dma_common_pages_remap() if the allocation is
coherent? In the __dma_alloc() case we don't do it but simply use
page_address(page) as returned by __dma_alloc_coherent().
(note that my comment is not meant to fix the issue reported by Andrzej
Hajda but I just spotted it)
--
Catalin
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size
On 4/20/2017 11:59 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote:
When System Memory Encryption (SME) is enabled, the physical address
space is reduced. Adjust the x86_phys_bits value to reflect this
reduction.
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/cpu/amd.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
...
@@ -622,8 +624,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
/* Check if SME is enabled */
rdmsrl(MSR_K8_SYSCFG, msr);
- if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
+ if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT) {
+ unsigned int ebx;
+
+ ebx = cpuid_ebx(0x801f);
+ c->x86_phys_bits -= (ebx >> 6) & 0x3f;
+ } else {
clear_cpu_cap(c, X86_FEATURE_SME);
+ }
Lemme do some simplifying to save an indent level, get rid of local var
ebx and kill some { }-brackets for a bit better readability:
if (c->extended_cpuid_level >= 0x801f) {
u64 msr;
if (!cpu_has(c, X86_FEATURE_SME))
return;
/* Check if SME is enabled */
rdmsrl(MSR_K8_SYSCFG, msr);
if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT)
c->x86_phys_bits -= (cpuid_ebx(0x801f) >> 6) & 0x3f;
else
clear_cpu_cap(c, X86_FEATURE_SME);
}
Hmmm... and actually if cpu_has(X86_FEATURE_SME) is true then it's a
given that extended_cpuid_level >= 0x801f. So this can be
simplified to just:
if (cpu_has(c, X86_FEATURE_SME)) {
... the rest of your suggestion (minus cpu_has()) ...
}
Thanks,
Tom
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size
On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote:
> When System Memory Encryption (SME) is enabled, the physical address
> space is reduced. Adjust the x86_phys_bits value to reflect this
> reduction.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/kernel/cpu/amd.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
...
> @@ -622,8 +624,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
>
> /* Check if SME is enabled */
> rdmsrl(MSR_K8_SYSCFG, msr);
> - if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
> + if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT) {
> + unsigned int ebx;
> +
> + ebx = cpuid_ebx(0x801f);
> + c->x86_phys_bits -= (ebx >> 6) & 0x3f;
> + } else {
> clear_cpu_cap(c, X86_FEATURE_SME);
> + }
Lemme do some simplifying to save an indent level, get rid of local var
ebx and kill some { }-brackets for a bit better readability:
if (c->extended_cpuid_level >= 0x801f) {
u64 msr;
if (!cpu_has(c, X86_FEATURE_SME))
return;
/* Check if SME is enabled */
rdmsrl(MSR_K8_SYSCFG, msr);
if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT)
c->x86_phys_bits -= (cpuid_ebx(0x801f) >> 6) & 0x3f;
else
clear_cpu_cap(c, X86_FEATURE_SME);
}
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: make iommu_bus_notifier return NOTIFY_DONE rather than error code
On Tue, Apr 18, 2017 at 08:51:48PM +0800, zhichang.yuan wrote: > In iommu_bus_notifier(), when action is BUS_NOTIFY_ADD_DEVICE, it will return > 'ops->add_device(dev)' directly. But ops->add_device will return ERR_VAL, such > as -ENODEV. These value will make notifier_call_chain() not to traverse the > remain nodes in struct notifier_block list. > > This patch revises iommu_bus_notifier() to return NOTIFY_DONE when some errors > heppened in ops->add_device(). > > Signed-off-by: zhichang.yuan Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/7] iommu/omap: Add support for iommu-groups and 'struct iommu_device'
Hi Suman, On Wed, Apr 12, 2017 at 12:21:25AM -0500, Suman Anna wrote: > I have taken the liberty of refreshing the series you have posted > based on my testing and review comments. My unit tests are passing > now with the series. I have summarized the changes below and also > outlined the changes in each patch. Great, thanks a lot. I've applied the patches to the arm/omap branch. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V11 00/11] IOMMU probe deferral support
On Mon, Apr 10, 2017 at 04:50:55PM +0530, Sricharan R wrote: > arch/arm64/mm/dma-mapping.c | 142 > +- > drivers/acpi/arm64/iort.c | 48 - > drivers/acpi/glue.c | 5 -- > drivers/acpi/scan.c | 11 ++- > drivers/base/dd.c | 9 +++ > drivers/base/dma-mapping.c| 41 +++ > drivers/iommu/arm-smmu-v3.c | 46 +--- > drivers/iommu/arm-smmu.c | 110 + > drivers/iommu/of_iommu.c | 126 - > drivers/of/device.c | 23 +- > drivers/of/platform.c | 10 +-- > drivers/pci/probe.c | 28 > include/acpi/acpi_bus.h | 2 +- > include/asm-generic/vmlinux.lds.h | 1 - > include/linux/acpi.h | 7 +- > include/linux/acpi_iort.h | 3 - > include/linux/dma-mapping.h | 12 > include/linux/of_device.h | 10 ++- > 18 files changed, 312 insertions(+), 322 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/ipmmu-vmsa: Fix pgsize_bitmap semicolon typo
From: Magnus Damm Fix comman-instead-of-semicolon typo error present in the latest version of the IPMMU driver. Will in the future be rolled into next driver update. Signed-off-by: Magnus Damm --- Applies on top of renesas-drivers-2017-04-18-v4.11-rc7 or -next plus: [PATCH v7 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V7 [PATCH v3 00/09] iommu/ipmmu-vmsa: r8a7795 support V3 [PATCH v3 0/3] iommu/ipmmu-vmsa: r8a7796 support V3 drivers/iommu/ipmmu-vmsa.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 0001/drivers/iommu/ipmmu-vmsa.c +++ work/drivers/iommu/ipmmu-vmsa.c 2017-04-20 22:30:07.000607110 +0900 @@ -431,7 +431,7 @@ static int ipmmu_domain_init_context(str * non-secure mode. */ domain->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS; - domain->cfg.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K, + domain->cfg.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K; domain->cfg.ias = 32; domain->cfg.oas = 40; domain->cfg.tlb = &ipmmu_gather_ops; ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
On Wed, Apr 19, 2017 at 7:25 PM, Jon Masters wrote: > One additional footnote. I spent a bunch of time recently on my personal > Xeon systems walking through the PCIe topology and aligning on how to > advise the ARM server community proceed going forward. If you look at > how Intel vs AMD handle their host bridges for example, you'll see two > very different approaches to the case of cross-socket PCIe. As a learning opportunity for me, can you share "lspci -vv" examples that show this Intel vs AMD difference? Maybe the ACPI host bridge descriptions from dmesg are relevant too? > But my > operating assumption is that anything longer term which looks boring and > x86 enough is probably fine from an ARM server point of view. That sounds pretty safe to me. Bjorn ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
