Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

On 09/14/2016 09:51 AM, Borislav Petkov wrote: > On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: >> This is still required because just using the __va() would still cause >> the mapping created to have the encryption bit set. The ioremap call >> will result in the mapping not having

Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption

On 09/14/2016 09:41 AM, Borislav Petkov wrote: > On Wed, Sep 14, 2016 at 08:45:44AM -0500, Tom Lendacky wrote: >> Currently, mem_encrypt.h only lives in the arch/x86 directory so it >> wouldn't be able to be included here without breaking other archs. > > I'm wondering if it would be simpler to

Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

On 09/15/2016 04:57 AM, Matt Fleming wrote: > On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote: >> On 09/12/2016 11:55 AM, Andy Lutomirski wrote: >>> On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote: BOOT data (such as EFI related data) is not encyrpted when the

Re: [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU

Hi Robin, On 15/09/2016 12:15, Robin Murphy wrote: > On 15/09/16 10:29, Auger Eric wrote: >> Hi Robin, >> >> On 14/09/2016 14:53, Robin Murphy wrote: >>> On 14/09/16 13:32, Auger Eric wrote: Hi, On 14/09/2016 12:35, Robin Murphy wrote: > On 14/09/16 09:41, Auger Eric wrote: >>

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote: > On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote: > > Hi, > > > > This series tries to solve the problem with DMA with device registers > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A > >

[PATCH v5 0/8] Fix kdump faults on system with amd iommu

This is v5 post. In fact in v3 the solution is correct. Just unluckily I got a AMD machine with bnx2 NIC which can't reset itself during driver init. It made me very unconfident with my understanding about the fix. Now with below fix the AMD machine with bnx2 NIC can also work well to dump and

[PATCH v5 8/8] iommu/amd: Update domain into to dte entry during device driver init

All devices are supposed to reset themselves at device driver initialization stage. At this time if in kdump kernel those on-flight DMA will be stopped because of device reset. It's best time to update the protection domain info, especially pte_root, to dte entry which the device relates to.

[PATCH v5 7/8] iommu/amd: Don't update domain info to dte entry at iommu init stage

AMD iommu creates protection domain and assign each device to it during iommu driver initialization stage. This happened just after system pci bus scanning stage, and much earlier than device driver init stage. So at this time if in kdump kernel the domain info, especially pte_root, can't be

[PATCH v5 4/8] iommu/amd: Add function copy_dev_tables

Add function copy_dev_tables to copy the old DEV table entry of the panicked kernel to the new allocated DEV table. Since all iommu share the same DTE table the copy only need be done once as long as the physical address of old DEV table is retrieved from iommu reg. Besides the old domain id

[PATCH v5 6/8] iommu/amd: Do not re-enable dev table entries in kdump

This enabling should have been done in normal kernel. It's unnecessary to enable it again in kdump kernel. And clean up the function comments of init_device_table_dma. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 10 +++--- 1 file changed, 7

[PATCH v5 3/8] iommu/amd: Define bit fields for DTE particularly

In amd-vi spec several bits of IO PTE fields and DTE fields are similar so that both of them can share the same MACRO definition. However defining their respecitve bit fields can make code more read-able. So do it in this patch. Signed-off-by: Baoquan He ---

[PATCH v5 5/8] iommu/amd: copy old trans table from old kernel

Here several things need be done: 1) If iommu is pre-enabled in a normal kernel, just disable it and print warning. 2) If failed to copy dev table of old kernel, continue to proceed as it does in normal kernel. 3) Re-enable event/cmd buffer and install the new DTE table to reg. 4) Flush all

[PATCH v5 2/8] iommu/amd: add early_enable_iommu() wrapper function

Move per iommu enabling code into a wrapper function early_enable_iommu(). This can make later kdump change easier. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git

[PATCH v5 1/8] iommu/amd: Detect pre enabled translation

Add functions to check whether translation is already enabled in IOMMU. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 25 + drivers/iommu/amd_iommu_proto.h | 1 + drivers/iommu/amd_iommu_types.h | 4 3 files changed, 30

Re: [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU

On 15/09/16 10:29, Auger Eric wrote: > Hi Robin, > > On 14/09/2016 14:53, Robin Murphy wrote: >> On 14/09/16 13:32, Auger Eric wrote: >>> Hi, >>> On 14/09/2016 12:35, Robin Murphy wrote: On 14/09/16 09:41, Auger Eric wrote: > Hi, > > On 12/09/2016 18:13, Robin Murphy wrote:

Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote: > On 09/12/2016 11:55 AM, Andy Lutomirski wrote: > > On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote: > >> > >> BOOT data (such as EFI related data) is not encyrpted when the system is > >> booted and needs to be accessed

Re: [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU

Hi Robin, On 14/09/2016 14:53, Robin Murphy wrote: > On 14/09/16 13:32, Auger Eric wrote: >> Hi, >> On 14/09/2016 12:35, Robin Murphy wrote: >>> On 14/09/16 09:41, Auger Eric wrote: Hi, On 12/09/2016 18:13, Robin Murphy wrote: > Hi all, > > To any more confusing fixups

Re: [PATCH v2] iommu/amd: Don't put completion-wait semaphore on stack

* Joerg Roedel wrote: > Hi Ingo, > > On Thu, Sep 15, 2016 at 07:44:35AM +0200, Ingo Molnar wrote: > > Yeah, I can still remove it - just zapped it in fact. > > Thanks, and sorry for the hassle. Here is the v2 patch that has the > correct locking. I tested it with and without

[PATCH 4/4] iommu/amd: No need to wait iommu completion if no dte irq entry change

This is a clean up. In get_irq_table() only if DTE entry is changed iommu_completion_wait() need be called. Otherwise no need to do it. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 0/4] iommu/amd: Clean up patches

These were found out when I tried to fix the kdump failure on system with AMD iommu. Pack them into this patchset since they are not related to the kdump issue and each other. Baoquan He (4): iommu/amd: clean up the cmpxchg64 invocation iommu/amd: Use standard bitmap operation to set bitmap

[PATCH 3/4] iommu/amd: Free domain id when free a domain of struct dma_ops_domain

The current code missed freeing domain id when free a domain of struct dma_ops_domain. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 160fc6a..a9f78c2

[PATCH 2/4] iommu/amd: Use standard bitmap operation to set bitmap

It will be more readable and safer than the old setting. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 59741ea..3e810c6

[PATCH 1/4] iommu/amd: clean up the cmpxchg64 invocation

Change it as it's designed for and keep it consistent with other places. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 96de97a..160fc6a

Re: [PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows

Hi Robin, On 2016-09-14 15:25, Robin Murphy wrote: On 14/09/16 13:35, Marek Szyprowski wrote: On 2016-09-14 13:10, Robin Murphy wrote: On 14/09/16 11:55, Marek Szyprowski wrote: On 2016-09-12 18:14, Robin Murphy wrote: With our DMA ops enabled for PCI devices, we should avoid allocating