[PATCH v3 3/6] iommu/iova: adjust __cached_rbnode_insert_update

For case 2 and 3, adjust cached32_node to the new place, case 1 keep no change. For example: case1: (the right part was allocated) |--| |<-free>|<--new_iova-->| | | cached32_node case2: (all was allocated)

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote: > I was worried what the compiler might do when CONFIG_EFI is not set, > but it appears to take care of it. I'll double check though. There's a efi_enabled() !CONFIG_EFI version too, so should be fine. > I may introduce a length

Re: [PATCH 1/3] iommu: of: Fix check for returning EPROBE_DEFER

Hi Bjorn, On 5/17/2017 10:34 PM, Bjorn Helgaas wrote: > On Wed, May 17, 2017 at 05:00:07PM +0530, Sricharan R wrote: >> Now with iommu probe deferral, we return -EPROBE_DEFER >> for master's that are connected to an iommu which is not > > s/master's/masters/ > > s/iommu/IOMMU/ in your English

Re: [PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

On Wed, May 17, 2017 at 03:26:58PM -0500, Tom Lendacky wrote: > > Also, simplify that test: > > > > if (mpf->feature1) > > ... > > Ok, I can do that but I hope no one says anything about it being > unrelated to the patch. :) Bah, that's minor. -- Regards/Gruss, Boris.

[PATCH v3 0/6] iommu/iova: improve the allocation performance of dma64

v2 -> v3: It's been a long time. I have not received any advise except Robin Murphy's. So the major changes is just deleted an old patch ("iommu/iova: fix incorrect variable types") and merged it into patch 5 of this version. v1 -> v2: Because the problem of my email-server, all patches sent to

[PATCH v3 4/6] iommu/iova: to optimize the allocation performance of dma64

Currently we always search free iova space for dma64 begin at the last node of iovad rb-tree. In the worst case, there maybe too many nodes exist at the tail, so that we should traverse many times for the first loop in __alloc_and_insert_iova_range. As we traced, more than 10K times for the case

[PATCH v3 6/6] iommu/iova: fix iovad->dma_32bit_pfn as the last pfn of dma32

To make sure iovad->cached32_node and iovad->cached64_node can exactly control dma32 and dma64 area. It also help us to remove the parameter pfn_32bit of init_iova_domain. Signed-off-by: Zhen Lei --- drivers/iommu/amd_iommu.c| 7 ++-

[PATCH v3 5/6] iommu/iova: move the caculation of pad mask out of loop

I'm not sure whether the compiler can optimize it, but move it out will be better. At least, it does not require lock protection. Signed-off-by: Zhen Lei --- drivers/iommu/iova.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff

[PATCH v3 2/6] iommu/iova: insert start_pfn boundary of dma32

Reserve the first granule size memory(start at start_pfn) as boundary iova, to make sure that iovad->cached32_node can not be NULL in future. Meanwhile, changed the assignment of iovad->cached32_node from rb_next to rb_prev of >node in function __cached_rbnode_delete_update. Signed-off-by: Zhen

Re: [Qemu-devel] [RFC PATCH 5/8] VFIO: Add new IOTCL for PASID Table bind propagation

On 17/05/17 11:27, Liu, Yi L wrote: > On Fri, May 12, 2017 at 03:58:51PM -0600, Alex Williamson wrote: >> On Wed, 26 Apr 2017 18:12:02 +0800 >> "Liu, Yi L" wrote: >>> >>> +/* IOCTL for Shared Virtual Memory Bind */ >>> +struct vfio_device_svm { >>> + __u32 argsz; >>>

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 4:09 PM, Laurent Pinchart wrote: > Hi Sricharan, > > Thank you for the patch. > > On Thursday 18 May 2017 15:37:09 Sricharan R wrote: >> While deferring the probe of IOMMU masters, >> xlate and add_device callback can pass back error values >> like -ENODEV, which means

[PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

While deferring the probe of IOMMU masters, xlate and add_device callback can pass back error values like -ENODEV, which means IOMMU cannot be connected with that master for real reasons. So rather than killing the master's probe for such errors, just ignore the errors and let the master work

[PATCH V2 1/3] iommu: of: Fix check for returning EPROBE_DEFER

Now with IOMMU probe deferral, we return -EPROBE_DEFER for masters that are connected to an IOMMU which is not probed yet, but going to get probed, so that we can attach the correct dma_ops. So while trying to defer the probe of the master, check if the of_iommu node that it is connected to is

[PATCH V2 3/3] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific

Re: [Qemu-devel] [RFC PATCH 5/8] VFIO: Add new IOTCL for PASID Table bind propagation

On Fri, May 12, 2017 at 03:58:51PM -0600, Alex Williamson wrote: > On Wed, 26 Apr 2017 18:12:02 +0800 > "Liu, Yi L" wrote: > > > From: "Liu, Yi L" > > > > This patch adds VFIO_IOMMU_SVM_BIND_TASK for potential PASID table > > binding requests. > >

Re: [PATCH V2 1/3] iommu: of: Fix check for returning EPROBE_DEFER

Hi Sricharan, Thank you for the patch. On Thursday 18 May 2017 15:37:08 Sricharan R wrote: > Now with IOMMU probe deferral, we return -EPROBE_DEFER > for masters that are connected to an IOMMU which is not > probed yet, but going to get probed, so that we can attach > the correct dma_ops. So

Re: [RFC PATCH 4/8] iommu/vt-d: Add iommu do invalidate function

On Fri, May 12, 2017 at 03:59:18PM -0600, Alex Williamson wrote: > On Wed, 26 Apr 2017 18:12:01 +0800 > "Liu, Yi L" wrote: > > > From: Jacob Pan > > > > This patch adds Intel VT-d specific function to implement > > iommu_do_invalidate API. > >

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Sricharan, Thank you for the patch. On Thursday 18 May 2017 15:37:09 Sricharan R wrote: > While deferring the probe of IOMMU masters, > xlate and add_device callback can pass back error values > like -ENODEV, which means IOMMU cannot be connected > with that master for real reasons. So rather

Re: [v6 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On Tue, May 16, 2017 at 5:45 AM, Rob Herring wrote: > DT changes should go to DT list. > > On Fri, May 12, 2017 at 7:41 AM, Geetha sowjanya > wrote: >> From: Linu Cherian >> >> Cavium ThunderX2 SMMU implementation doesn't

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote: > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > determine if SME is active. But why do user-space tools need to know that? I mean, when we load the kdump kernel, we do it with the first kernel, with the

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 6:00 PM, Laurent Pinchart wrote: > Hi Sricharan, > > On Thursday 18 May 2017 17:26:14 Sricharan R wrote: >> On 5/18/2017 4:09 PM, Laurent Pinchart wrote: >>> On Thursday 18 May 2017 15:37:09 Sricharan R wrote: While deferring the probe of IOMMU masters, xlate

Re: [PATCH V4 2/4] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Sricharan, Thank you for the patch. On Thursday 18 May 2017 20:24:15 Sricharan R wrote: > While deferring the probe of IOMMU masters, xlate and > add_device callbacks called from of_iommu_configure > can pass back error values like -ENODEV, which means > the IOMMU cannot be connected with

[PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

While deferring the probe of IOMMU masters, xlate and add_device callbacks called from iort_iommu_configure can pass back error values like -ENODEV, which means the IOMMU cannot be connected with that master for real reasons. Before the IOMMU probe deferral, all such errors were ignored. Now all

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Tue, Apr 18, 2017 at 04:21:49PM -0500, Tom Lendacky wrote: > Add the support to encrypt the kernel in-place. This is done by creating > new page mappings for the kernel - a decrypted write-protected mapping > and an encrypted mapping. The kernel is encrypted by copying it through > a temporary

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Sricharan On Thursday 18 May 2017 19:08:12 Sricharan R wrote: > On 5/18/2017 6:00 PM, Laurent Pinchart wrote: > > On Thursday 18 May 2017 17:26:14 Sricharan R wrote: > >> On 5/18/2017 4:09 PM, Laurent Pinchart wrote: > >>> On Thursday 18 May 2017 15:37:09 Sricharan R wrote: > While

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 7:13 PM, Laurent Pinchart wrote: > Hi Sricharan > > On Thursday 18 May 2017 19:08:12 Sricharan R wrote: >> On 5/18/2017 6:00 PM, Laurent Pinchart wrote: >>> On Thursday 18 May 2017 17:26:14 Sricharan R wrote: On 5/18/2017 4:09 PM, Laurent Pinchart wrote: > On

[PATCH V4 1/4] iommu: of: Fix check for returning EPROBE_DEFER

Now with IOMMU probe deferral, we return -EPROBE_DEFER for masters that are connected to an IOMMU which is not probed yet, but going to get probed, so that we can attach the correct dma_ops. So while trying to defer the probe of the master, check if the of_iommu node that it is connected to is

[PATCH V4 4/4] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific

[PATCH V4 2/4] iommu: of: Ignore all errors except EPROBE_DEFER

While deferring the probe of IOMMU masters, xlate and add_device callbacks called from of_iommu_configure can pass back error values like -ENODEV, which means the IOMMU cannot be connected with that master for real reasons. Before the IOMMU probe deferral, all such errors were ignored. Now all

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote: > On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote: > > > + paddr = boot_params.efi_info.efi_memmap_hi; > > + paddr <<= 32; > > + paddr |= boot_params.efi_info.efi_memmap; > > + if (phys_addr

Re: [PATCH v6 2/3] iommu/pci: reserve IOVA for PCI masters

On Wed, May 17, 2017 at 10:41 PM, Bjorn Helgaas wrote: > On Tue, May 16, 2017 at 10:52:06AM +0530, Oza Pawandeep wrote: >> this patch reserves the IOVA for PCI masters. >> ARM64 based SOCs may have scattered memory banks. >> such as iproc based SOC has >> >> <0x

Re: [PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Thu, May 18, 2017 at 12:43 AM, Arnd Bergmann wrote: > On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote: >> current device framework and OF framework integration assumes >> dma-ranges in a way where memory-mapped devices define their >> dma-ranges.

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only

On 07/04/17 07:20 PM, Joerg Roedel wrote: > On Mon, Mar 27, 2017 at 11:47:07AM +0530, arindam.n...@amd.com wrote: >> From: Arindam Nath >> >> The idea behind flush queues is to defer the IOTLB flushing >> for domains for which the mappings are no longer valid. We >> add such

Re: [PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Wed, May 17, 2017 at 10:40 PM, Bjorn Helgaas wrote: > On Tue, May 16, 2017 at 10:52:05AM +0530, Oza Pawandeep wrote: >> current device framework and OF framework integration assumes > > s/current/The current/ > >> dma-ranges in a way where memory-mapped devices define their

Re: [Qemu-devel] [RFC PATCH 09/20] Memory: introduce iommu_ops->record_device

Hi Alex, What's your opinion with Tianyu's question? Is it accepatable to use VFIO API in intel_iommu emulator? Thanks, Yi L On Fri, Apr 28, 2017 at 02:46:16PM +0800, Lan Tianyu wrote: > On 2017年04月26日 18:06, Liu, Yi L wrote: > > With vIOMMU exposed to guest, vIOMMU emulator needs to do

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Sricharan, On Thursday 18 May 2017 17:26:14 Sricharan R wrote: > On 5/18/2017 4:09 PM, Laurent Pinchart wrote: > > On Thursday 18 May 2017 15:37:09 Sricharan R wrote: > >> While deferring the probe of IOMMU masters, > >> xlate and add_device callback can pass back error values > >> like