Re: [PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

On Thu, Jun 08, 2017 at 03:25:42PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > arch/hexagon/include/asm/dma-mapping.h | 2 -- > arch/hexagon/kernel/dma.c | 12 +--- > arch/hexagon/kernel/hexagon_ksyms.c| 1 - > 3 files

Re: [PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

On Thu, Jun 08, 2017 at 03:25:56PM +0200, Christoph Hellwig wrote: > This implementation is simply bogus - hexagon only has a simple > direct mapped DMA implementation and thus doesn't care about the > address. > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On June 15, 2017 11:33:22 AM EDT, Borislav Petkov wrote: >On Thu, Jun 15, 2017 at 09:59:45AM -0500, Tom Lendacky wrote: >> Actually the detection routine, amd_iommu_detect(), is part of the >> IOMMU_INIT_FINISH macro support which is called early through >mm_init() >> from

Re: [PATCH v6 30/34] x86/mm, kexec: Allow kexec to be used with SME

On 6/15/2017 5:03 AM, Borislav Petkov wrote: On Wed, Jun 07, 2017 at 02:18:27PM -0500, Tom Lendacky wrote: Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to be able to

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On 6/15/2017 10:33 AM, Borislav Petkov wrote: On Thu, Jun 15, 2017 at 09:59:45AM -0500, Tom Lendacky wrote: Actually the detection routine, amd_iommu_detect(), is part of the IOMMU_INIT_FINISH macro support which is called early through mm_init() from start_kernel() and that routine is called

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Thu, Jun 15, 2017 at 09:59:45AM -0500, Tom Lendacky wrote: > Actually the detection routine, amd_iommu_detect(), is part of the > IOMMU_INIT_FINISH macro support which is called early through mm_init() > from start_kernel() and that routine is called before init_amd(). Ah, we do that there

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On 6/15/2017 4:41 AM, Borislav Petkov wrote: On Wed, Jun 14, 2017 at 03:40:28PM -0500, Tom Lendacky wrote: I was trying to keep all the logic for it here in the SME related files rather than put it in the iommu code itself. But it is easy enough to move if you think it's worth it. Yes please

Re: [PATCH v3 2/2] acpi/iort: numa: Add numa node mapping for smmuv3 devices

Hi, On Thu, Jun 08, 2017 at 10:14:19AM +0530, Ganapatrao Kulkarni wrote: > Add code to parse proximity domain in SMMUv3 IORT table to > set numa node mapping for smmuv3 devices. > > Signed-off-by: Ganapatrao Kulkarni > --- > drivers/acpi/arm64/iort.c | 28

Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

On 6/15/2017 4:08 AM, Borislav Petkov wrote: On Wed, Jun 14, 2017 at 02:49:02PM -0500, Tom Lendacky wrote: I guess I don't need the sme_active() check since the second part of the if statement can only ever be true if SME is active (since mask is unsigned). ... and you can define sme_me_mask

[PATCH 0/2 v2] iommu/s390: Improve iommu-groups and add sysfs support

Hey, here are two patches for the s390 iommu driver. The first one optimizes iommu-group creation by making use of iommu_group_get_for_dev(). The second one adds support for the iommu_device_register interface and with that also sysfs support. Any comments and testing appreciated. Thanks,

[PATCH 2/2] iommu/s390: Add support for iommu_device handling

From: Joerg Roedel Add support for the iommu_device_register interface to make the s390 hardware iommus visible to the iommu core and in sysfs. Signed-off-by: Joerg Roedel --- arch/s390/include/asm/pci.h | 7 +++ arch/s390/pci/pci.c | 5 +

[PATCH 1/2] iommu/s390: Use iommu_group_get_for_dev() in s390_iommu_add_device()

From: Joerg Roedel The iommu_group_get_for_dev() function also attaches the device to its group, so this code doesn't need to be in the iommu driver. Further by using this function the driver can make use of default domains in the future. Signed-off-by: Joerg Roedel

Re: [PATCH 0/8] io-pgtable lock removal

On 15/06/2017 01:40, Ray Jui via iommu wrote: Hi Robin, wangzhou tested this patchset on our SMMUv3-based development board with a 10G PCI NIC card. Currently we see a ~17% performance (throughput) drop when enabling the SMMU, but only a ~8% drop with your patchset. FYI, for our

[PATCH 04/04] iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids

From: Magnus Damm Now when both 32-bit and 64-bit code inside the driver is using fwspec it is possible to replace the utlb handling with fwspec ids that get populated from ->of_xlate(). Suggested-by: Robin Murphy Signed-off-by: Magnus Damm

[PATCH 02/04] iommu/ipmmu-vmsa: Consistent ->of_xlate() handling

From: Magnus Damm The 32-bit ARM code gets updated to make use of ->of_xlate() and the code is shared between 64-bit and 32-bit ARM. The of_device_is_available() check gets dropped since it is included in of_iommu_xlate(). Suggested-by: Robin Murphy

[PATCH 03/04] iommu/ipmmu-vmsa: Use fwspec on both 32 and 64-bit ARM

From: Robin Murphy Consolidate the 32-bit and 64-bit code to make use of fwspec instead of archdata for the 32-bit ARM case. This is a simplified version of the fwspec handling code from Robin posted as [PATCH] iommu/ipmmu-vmsa: Convert to iommu_fwspec Signed-off-by:

[PATCH 01/04] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister()

From: Magnus Damm Extend the driver to make use of iommu_device_register()/unregister() functions together with iommu_device_set_ops() and iommu_set_fwnode(). These used to be part of the earlier posted 64-bit ARM (r8a7795) series but it turns out that these days

[PATCH 00/04] iommu/ipmmu-vmsa: 32-bit ARM update

iommu/ipmmu-vmsa: 32-bit ARM update [PATCH 01/04] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister() [PATCH 02/04] iommu/ipmmu-vmsa: Consistent ->of_xlate() handling [PATCH 03/04] iommu/ipmmu-vmsa: Use fwspec on both 32 and 64-bit ARM [PATCH 04/04] iommu/ipmmu-vmsa: Replace local utlb

Re: [PATCH v6 30/34] x86/mm, kexec: Allow kexec to be used with SME

On Wed, Jun 07, 2017 at 02:18:27PM -0500, Tom Lendacky wrote: > Provide support so that kexec can be used to boot a kernel when SME is > enabled. > > Support is needed to allocate pages for kexec without encryption. This > is needed in order to be able to reboot in the kernel in the same manner

Re: [PATCH v6 29/34] kvm: x86: svm: Support Secure Memory Encryption within KVM

On Wed, Jun 07, 2017 at 02:18:15PM -0500, Tom Lendacky wrote: > Update the KVM support to work with SME. The VMCB has a number of fields > where physical addresses are used and these addresses must contain the > memory encryption mask in order to properly access the encrypted memory. > Also, use

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Wed, Jun 14, 2017 at 03:40:28PM -0500, Tom Lendacky wrote: > I was trying to keep all the logic for it here in the SME related files > rather than put it in the iommu code itself. But it is easy enough to > move if you think it's worth it. Yes please - the less needlessly global symbols, the

Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

On Wed, Jun 14, 2017 at 02:49:02PM -0500, Tom Lendacky wrote: > I guess I don't need the sme_active() check since the second part of the > if statement can only ever be true if SME is active (since mask is > unsigned). ... and you can define sme_me_mask as an u64 directly (it is that already,