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

* Joerg Roedel wrote: > On Wed, Sep 14, 2016 at 11:27:12PM +0200, Joerg Roedel wrote: > > On Wed, Sep 14, 2016 at 05:26:48PM +0200, Ingo Molnar wrote: > > > > > > Cool, thanks! I'll put this into tip:x86/asm which has the virtually > > > mapped stack > > > patches - ok? > >

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

On Wed, Sep 14, 2016 at 11:27:12PM +0200, Joerg Roedel wrote: > On Wed, Sep 14, 2016 at 05:26:48PM +0200, Ingo Molnar wrote: > > > > Cool, thanks! I'll put this into tip:x86/asm which has the virtually mapped > > stack > > patches - ok? > > Yeah, sure, that is the best thing to do. Just wait

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

Hi Ingo, On Wed, Sep 14, 2016 at 05:26:48PM +0200, Ingo Molnar wrote: > > Cool, thanks! I'll put this into tip:x86/asm which has the virtually mapped > stack > patches - ok? Yeah, sure, that is the best thing to do. Just wait for the v2 I'll sending tomorrow. I just realised that the locking

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

* Joerg Roedel wrote: > From: Joerg Roedel > > The semaphore used by the AMD IOMMU to signal command > completion lived on the stack until now, which was safe as > the driver busy-waited on the semaphore with IRQs disabled, > so the stack can't go away under

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

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 the encryption bit set. I meant this:

Re: [RFC PATCH v2 20/20] x86: Add support to make use of Secure Memory Encryption

On 09/12/2016 12:08 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:39:08PM -0500, Tom Lendacky wrote: >> This patch adds the support to check if SME has been enabled and if the >> mem_encrypt=on command line option is set. If both of these conditions >> are true, then the encryption mask

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

On 09/12/2016 11:59 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote: >> Since the setup data is in memory in the clear, it must be accessed as >> un-encrypted. Always use ioremap (similar to sysfs setup data support) >> to map the data. >> >>

[PATCH v7.1 19/22] iommu/arm-smmu: Wire up generic configuration support

With everything else now in place, fill in an of_xlate callback and the appropriate registration to plumb into the generic configuration machinery, and watch everything just work. Signed-off-by: Robin Murphy --- - Don't pull in of_platform.h for no reason (was an old

[PATCH v7.1 13/22] iommu/arm-smmu: Refactor mmu-masters handling

To be able to support the generic bindings and handle of_xlate() calls, we need to be able to associate SMMUs and stream IDs directly with devices *before* allocating IOMMU groups. Furthermore, to support real default domains with multi-device groups we also have to handle domain attach on a

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

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 as non-encrypted. Add support to the >> early_memremap API to

Re: [RFC PATCH v2 16/20] x86: Check for memory encryption on the APs

On 09/12/2016 11:43 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote: >> Add support to check if memory encryption is active in the kernel and that >> it has been enabled on the AP. If memory encryption is active in the kernel > > A small nit: let's

Re: [RFC PATCH v2 10/20] x86: Insure that memory areas are encrypted when possible

On 09/12/2016 11:33 AM, Borislav Petkov wrote: > On Mon, Sep 12, 2016 at 10:05:36AM -0500, Tom Lendacky wrote: >> I can look into that. The reason I put this here is this is all the >> early page fault support that is very specific to this file. I modified >> an existing static function to take

Re: [RFC PATCH v2 18/20] x86/kvm: Enable Secure Memory Encryption of nested page tables

On 09/12/2016 09:35 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:49PM -0500, Tom Lendacky wrote: >> Update the KVM support to include the memory encryption mask when creating >> and using nested page tables. >> >> Signed-off-by: Tom Lendacky >> --- >>

Re: [RFC PATCH v2 16/20] x86: Check for memory encryption on the APs

On 09/12/2016 07:17 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote: >> Add support to check if memory encryption is active in the kernel and that >> it has been enabled on the AP. If memory encryption is active in the kernel >> but has not been enabled on

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

On 09/12/2016 06:45 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote: >> Add support to the AMD IOMMU driver to set the memory encryption mask if >> memory encryption is enabled. >> >> Signed-off-by: Tom Lendacky >> --- >>

Re: [RFC PATCH v2 14/20] x86: DMA support for memory encryption

On 09/12/2016 05:58 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:07PM -0500, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does

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

On 14/09/16 13:35, Marek Szyprowski wrote: > Hi Robin, > > > 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 IOVAs which a host

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

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 and crazily numbered extra patches, here's a quick v7 with

[PATCH] iommu/exynos: Improve page fault debug message

Add master device name to default IOMMU fault message to make easier to find which device triggered the fault. While at it, move printing some information (like page table base and first level entry addresses) to dev_dbg(), because those are typically not very useful for typical device driver

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

Hi Robin, 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 IOVAs which a host bridge might misinterpret as peer-to-peer DMA and lead to faults,

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

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 and crazily numbered extra patches, here's >>> a quick v7 with everything rebased into the right order. The

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

[...] >>> To solve this problem, I was thinking we could convert to use the asynchronous pm_runtime_get() API, when trying to runtime resume the device from atomic contexts. >>> >>> I'm not sure if this will work for DMA engine devices. If I understand >>> correctly some client's

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

Hi Marek, On 14/09/16 11:55, Marek Szyprowski wrote: > Hi Robin, > > > On 2016-09-12 18:14, Robin Murphy wrote: >> With our DMA ops enabled for PCI devices, we should avoid allocating >> IOVAs which a host bridge might misinterpret as peer-to-peer DMA and >> lead to faults, corruption or other

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

Hi Robin, On 2016-09-12 18:14, Robin Murphy wrote: With our DMA ops enabled for PCI devices, we should avoid allocating IOVAs which a host bridge might misinterpret as peer-to-peer DMA and lead to faults, corruption or other badness. To be safe, punch out holes for all of the relevant host

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

Hi Ulf, On 2016-09-14 12:28, Ulf Hansson wrote: [...] There are some similarities between IOMMU and DMA engine devices (serial drivers are imho completely different case). Both hw blocks do their work on behalf of some other hardware block, which I will call master device. DMA engine

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

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 and crazily numbered extra patches, here's >> a quick v7 with everything rebased into the right order. The significant >> change this time is to implement

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

[...] > > > There are some similarities between IOMMU and DMA engine devices (serial > drivers are imho completely different case). Both hw blocks do their work > on behalf of some other hardware block, which I will call master device. > DMA engine performs some DMA transaction on master's device

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

From: Joerg Roedel The semaphore used by the AMD IOMMU to signal command completion lived on the stack until now, which was safe as the driver busy-waited on the semaphore with IRQs disabled, so the stack can't go away under the driver. But the recently introduced vmap-based

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

Hi Will On 14/09/2016 11:20, Will Deacon wrote: > On Wed, Sep 14, 2016 at 10:41:57AM +0200, Auger Eric wrote: >> Hi, > > Hi Eric, > >> On 12/09/2016 18:13, Robin Murphy wrote: >>> To any more confusing fixups and crazily numbered extra patches, here's >>> a quick v7 with everything rebased into

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

On Wed, Sep 14, 2016 at 10:41:57AM +0200, Auger Eric wrote: > Hi, Hi Eric, > On 12/09/2016 18:13, Robin Murphy wrote: > > To any more confusing fixups and crazily numbered extra patches, here's > > a quick v7 with everything rebased into the right order. The significant > > change this time is

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

Hi, On 12/09/2016 18:13, Robin Murphy wrote: > Hi all, > > To any more confusing fixups and crazily numbered extra patches, here's > a quick v7 with everything rebased into the right order. The significant > change this time is to implement iommu_fwspec properly from the start, > which ends up

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

Hi Ulf, On 2016-09-13 16:20, Ulf Hansson wrote: On 13 September 2016 at 14:49, Marek Szyprowski wrote: This patch uses recently introduced device links to track the runtime pm state of the master's device. This way each SYSMMU controller is runtime activated when its