Re: [PATCH 21/20] drm/exynos: Fix iommu_dma_init_domain prototype change

On Fri, Sep 09, 2016 at 07:17:46PM +0100, Robin Murphy wrote: > When adding an extra argument to a function, one really should try a bit > harder to catch *all* the callers... > > CC: Marek Szyprowski > CC: Inki Dae > CC: David Airlie

Re: [PATCH 4.5/20] Docs: dt: document ARM SMMUv3 generic binding usage

On Fri, Sep 09, 2016 at 07:17:48PM +0100, Robin Murphy wrote: > Now that we've ratified SMMUv3's use of the generic binding, document it. > > CC: Rob Herring > CC: Mark Rutland > Signed-off-by: Robin Murphy > --- >

Re: [PATCH 22/20] iommu/arm-smmu: Fall back to global bypass

On Fri, Sep 09, 2016 at 07:17:47PM +0100, Robin Murphy wrote: > Unlike SMMUv2, SMMUv3 has no easy way to bypass unknown stream IDs, > other than allocating and filling in the entire stream table with bypass > entries, which for some configurations would waste *gigabytes* of RAM. > Otherwise, all

RE: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

Hi Scott, Thanks for your review :) See my comment inline. > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Friday, September 09, 2016 11:47 AM > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd > Bergmann > Cc: linuxppc-...@lists.ozlabs.org;

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

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 not support 48-bits. SWIOTLB will be > initialized to

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

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 > --- > arch/x86/include/asm/mem_encrypt.h |2 ++ >

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

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 the AP then do not allow the AP to continue > start

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

On 09/08/2016 08:55 AM, Borislav Petkov wrote: > On Thu, Sep 08, 2016 at 08:26:27AM -0500, Tom Lendacky wrote: >> When does this value get initialized? Since _PAGE_ENC is #defined to >> sme_me_mask, which is not set until the boot process begins, I'm afraid >> we'd end up using the initial value

Re: [RFC PATCH v2 12/20] x86: Add support for changing memory encryption attribute

On 09/09/2016 12:23 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:37:49PM -0500, Tom Lendacky wrote: >> This patch adds support to be change the memory encryption attribute for >> one or more memory pages. >> >> Signed-off-by: Tom Lendacky >> --- >>

Re: [RFC PATCH v2 13/20] x86: Decrypt trampoline area if memory encryption is active

On 09/09/2016 12:34 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:37:57PM -0500, Tom Lendacky wrote: >> When Secure Memory Encryption is enabled, the trampoline area must not >> be encrypted. A cpu running in real mode will not be able to decrypt > > s/cpu/CPU/... always :-) Ok. > >>

[PATCH v7 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

[PATCH v7 12/22] iommu/arm-smmu: Keep track of S2CR state

Making S2CRs first-class citizens within the driver with a high-level representation of their state offers a neat solution to a few problems: Firstly, the information about which context a device's stream IDs are associated with is already present by necessity in the S2CR. With that state easily

[PATCH v7 07/22] iommu/arm-smmu: Implement of_xlate() for SMMUv3

Now that we can properly describe the mapping between PCI RIDs and stream IDs via "iommu-map", and have it fed it to the driver automatically via of_xlate(), rework the SMMUv3 driver to benefit from that, and get rid of the current misuse of the "iommus" binding. Since having of_xlate wired up

[PATCH v7 11/22] iommu/arm-smmu: Consolidate stream map entry state

In order to consider SMR masking, we really want to be able to validate ID/mask pairs against existing SMR contents to prevent stream match conflicts, which at best would cause transactions to fault unexpectedly, and at worst lead to silent unpredictable behaviour. With our SMMU instance data

[PATCH v7 21/22] iommu/dma: Add support for mapping MSIs

When an MSI doorbell is located downstream of an IOMMU, attaching devices to a DMA ops domain and switching on translation leads to a rude shock when their attempt to write to the physical address returned by the irqchip driver faults (or worse, writes into some already-mapped buffer) and no

[PATCH v7 20/22] iommu/arm-smmu: Set domain geometry

For non-aperture-based IOMMUs, the domain geometry seems to have become the de-facto way of indicating the input address space size. That is quite a useful thing from the users' perspective, so let's do the same. Reviewed-by: Eric Auger Tested-by: Lorenzo Pieralisi

[PATCH v7 17/22] iommu/arm-smmu: Convert to iommu_fwspec

In the final step of preparation for full generic configuration support, swap our fixed-size master_cfg for the generic iommu_fwspec. For the legacy DT bindings, the driver simply gets to act as its own 'firmware'. Farewell, arbitrary MAX_MASTER_STREAMIDS! Signed-off-by: Robin Murphy

[PATCH v7 10/22] iommu/arm-smmu: Handle stream IDs more dynamically

Rather than assuming fixed worst-case values for stream IDs and SMR masks, keep track of whatever implemented bits the hardware actually reports. This also obviates the slightly questionable validation of SMR fields in isolation - rather than aborting the whole SMMU probe for a hardware

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

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 being far simpler and more robust than faffing about

[PATCH v7 14/22] iommu/arm-smmu: Streamline SMMU data lookups

Simplify things somewhat by stashing our arm_smmu_device instance in drvdata, so that it's readily available to our driver model callbacks. Then we can excise the private list entirely, since the driver core already has a perfectly good list of SMMU devices we can use in the one instance we

[PATCH v7 08/22] iommu/arm-smmu: Support non-PCI devices with SMMUv3

With the device <-> stream ID relationship suitably abstracted and of_xlate() hooked up, the PCI dependency now looks, and is, entirely arbitrary. Any bus using the of_dma_configure() mechanism will work, so extend support to the platform and AMBA buses which do just that. Acked-by: Will Deacon

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

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 is set and the kernel is encrypted > "in place." >

Re: [RFC PATCH v2 12/20] x86: Add support for changing memory encryption attribute

On Mon, Sep 12, 2016 at 10:41:29AM -0500, Tom Lendacky wrote: > Looking at __change_page_attr_set_clr() isn't it possible for some of > the pages to be changed before an error is encountered since it is > looping? If so, we may still need to flush. The CPA_FLUSHTLB flag > should take care of a

[PATCH v7 02/22] of/irq: Break out msi-map lookup (again)

The PCI msi-map code is already doing double-duty translating IDs and retrieving MSI parents, which unsurprisingly is the same functionality we need for the identically-formatted PCI iommu-map property. Drag the core parsing routine up yet another layer into the general OF-PCI code, and further

[PATCH v7 05/22] Docs: dt: document ARM SMMUv3 generic binding usage

We're about to ratify our use of the generic binding, so document it. CC: Rob Herring CC: Mark Rutland Signed-off-by: Robin Murphy --- - Reference PCI "iommu-map" binding instead, as that's our main concern - Fix "IDs" typo ---

[PATCH v7 06/22] iommu/arm-smmu: Fall back to global bypass

Unlike SMMUv2, SMMUv3 has no easy way to bypass unknown stream IDs, other than allocating and filling in the entire stream table with bypass entries, which for some configurations would waste *gigabytes* of RAM. Otherwise, all transactions on unknown stream IDs will simply be aborted with a

[PATCH v7 03/22] iommu/of: Handle iommu-map property for PCI

Now that we have a way to pick up the RID translation and target IOMMU, hook up of_iommu_configure() to bring PCI devices into the of_xlate mechanism and allow them IOMMU-backed DMA ops without the need for driver-specific handling. Reviewed-by: Will Deacon Signed-off-by:

[PATCH v7 01/22] Docs: dt: add PCI IOMMU map bindings

From: Mark Rutland The existing IOMMU bindings are able to specify the relationship between masters and IOMMUs, but they are insufficient for describing the general case of hotpluggable busses such as PCI where the set of masters is not known until runtime, and the

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

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 write out "AP" the first time at least: "... on the

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

On Mon, Sep 12, 2016 at 10:14:59AM -0500, Tom Lendacky wrote: > I did run checkpatch against everything, but was always under the > assumption that I shouldn't change existing warnings/errors like this. > If it's considered ok since I'm touching that line of code then I'll > take care of those

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

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 identify the type of data being accessed so that >

[PATCH v7 04/22] iommu: Introduce iommu_fwspec

Introduce a common structure to hold the per-device firmware data that most IOMMU drivers need to keep track of. This enables us to configure much of that data from common firmware code, and consolidate a lot of the equivalent implementations, device look-up tables, etc. which are currently strewn

[PATCH v7 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 --- - Convert to updated fwspec mechanism ---

[PATCH v7 16/22] iommu/arm-smmu: Intelligent SMR allocation

Stream Match Registers are one of the more awkward parts of the SMMUv2 architecture; there are typically never enough to assign one to each stream ID in the system, and configuring them such that a single ID matches multiple entries is catastrophically bad - at best, every transaction raises a

[PATCH v7 15/22] iommu/arm-smmu: Add a stream map entry iterator

We iterate over the SMEs associated with a master config quite a lot in various places, and are about to do so even more. Let's wrap the idiom in a handy iterator macro before the repetition gets out of hand. Tested-by: Lorenzo Pieralisi Signed-off-by: Robin Murphy

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

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 bridge's windows when initialising a DMA domain for a PCI

[PATCH v7 18/22] Docs: dt: document ARM SMMU generic binding usage

Document how the generic "iommus" binding should be used to describe ARM SMMU stream IDs instead of the old "mmu-masters" binding. Acked-by: Rob Herring Signed-off-by: Robin Murphy --- - Remove missed reference to old "mmu-masters" example ---

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

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 advantage of the mapping support. Yeah, but all this

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

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. > > Signed-off-by: Tom Lendacky > --- >

Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

On Mon, 2016-09-12 at 06:39 +, Y.B. Lu wrote: > Hi Scott, > > Thanks for your review :) > See my comment inline. > > > > > -Original Message- > > From: Scott Wood [mailto:o...@buserror.net] > > Sent: Friday, September 09, 2016 11:47 AM > > To: Y.B. Lu; linux-...@vger.kernel.org;

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

On 09/09/2016 10:53 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:37:23PM -0500, Tom Lendacky wrote: >> Encrypt memory areas in place when possible (e.g. zero page, etc.) so >> that special handling isn't needed afterwards. >> >> Signed-off-by: Tom Lendacky >>

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

On 09/09/2016 11:38 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:37:38PM -0500, 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 identify the

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

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 > --- > arch/x86/include/asm/kvm_host.h |3 ++- >