DPAA2 triggers, [PATCH] dma debug: report -EEXIST errors in add_dma_entry

+DPAA2, netdev maintainers Hi, On 5/18/21 7:54 AM, Hamza Mahfooz wrote: Since, overlapping mappings are not supported by the DMA API we should report an error if active_cacheline_insert returns -EEXIST. It seems this patch found a victim. I was trying to run iperf3 on a honeycomb (5.14.0,

[PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

Replace uses of mem_encrypt_active() with calls to cc_platform_has() with the CC_ATTR_MEM_ENCRYPT attribute. Remove the implementation of mem_encrypt_active() across all arches. For s390, since the default implementation of the cc_platform_has() matches the s390 implementation of

[PATCH v3 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()

Replace uses of sev_es_active() with the more generic cc_platform_has() using CC_ATTR_GUEST_STATE_ENCRYPT. If future support is added for other memory encyrption techonologies, the use of CC_ATTR_GUEST_STATE_ENCRYPT can be updated, as required. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav

[PATCH v3 6/8] x86/sev: Replace occurrences of sev_active() with cc_platform_has()

Replace uses of sev_active() with the more generic cc_platform_has() using CC_ATTR_GUEST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_GUEST_MEM_ENCRYPT can be updated, as required. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov

[PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

Replace uses of sme_active() with the more generic cc_platform_has() using CC_ATTR_HOST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_HOST_MEM_ENCRYPT can be updated, as required. This also replaces two usages of sev_active() that are really

[PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

Introduce a powerpc version of the cc_platform_has() function. This will be used to replace the powerpc mem_encrypt_active() implementation, so the implementation will initially only support the CC_ATTR_MEM_ENCRYPT attribute. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras

[PATCH v3 3/8] x86/sev: Add an x86 version of cc_platform_has()

Introduce an x86 version of the cc_platform_has() function. This will be used to replace vendor specific calls like sme_active(), sev_active(), etc. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Co-developed-by: Andi Kleen

[PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

In prep for other confidential computing technologies, introduce a generic helper function, cc_platform_has(), that can be used to check for specific active confidential computing attributes, like memory encryption. This is intended to eliminate having to add multiple technology-specific checks to

[PATCH v3 1/8] x86/ioremap: Selectively build arch override encryption functions

In prep for other uses of the cc_platform_has() function besides AMD's memory encryption support, selectively build the AMD memory encryption architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These functions are: - early_memremap_pgprot_adjust() - arch_memremap_can_ram_remap()

[PATCH v3 0/8] Implement generic cc_platform_has() helper function

This patch series provides a generic helper function, cc_platform_has(), to replace the sme_active(), sev_active(), sev_es_active() and mem_encrypt_active() functions. It is expected that as new confidential computing technologies are added to the kernel, they can all be covered by a single

Re: [PATCH] iommu: Clarify default domain Kconfig

On Wed, Sep 8, 2021 at 5:55 AM Robin Murphy wrote: > > Although strictly it is the AMD and Intel drivers which have an existing > expectation of lazy behaviour by default, it ends up being rather > unintuitive to describe this literally in Kconfig. Express it instead as > an architecture

Re: [PATCH 00/12] swiotlb-xen: fixes and adjustments

On 07.09.21 14:03, Jan Beulich wrote: The primary intention really was the last patch, there you go ... 01: swiotlb-xen: avoid double free 02: swiotlb-xen: fix late init retry 03: swiotlb-xen: maintain slab count properly 04: swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests 05:

[PATCH] iommu: Clarify default domain Kconfig

Although strictly it is the AMD and Intel drivers which have an existing expectation of lazy behaviour by default, it ends up being rather unintuitive to describe this literally in Kconfig. Express it instead as an architecture dependency, to clarify that it is a valid config-time decision. The