Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

On 02/16/17 at 09:47am, Tom Lendacky wrote: > Use memremap() to map the setup data. This will make the appropriate > decision as to whether a RAM remapping can be done or if a fallback to > ioremap_cache() is needed (similar to the setup data debugfs support). > > Signed-off-by: Tom Lendacky

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

On 02/16/17 at 09:47am, Tom Lendacky wrote: > Use memremap() to map the setup data. This simplifies the code and will > make the appropriate decision as to whether a RAM remapping can be done > or if a fallback to ioremap_cache() is needed (which includes checking > PageHighMem). > >

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

On 02/16/17 at 09:45am, Tom Lendacky wrote: [snip] > + * This function determines if an address should be mapped encrypted. > + * Boot setup data, EFI data and E820 areas are checked in making this > + * determination. > + */ > +static bool memremap_should_map_encrypted(resource_size_t phys_addr,

Re: [PATCH 5/9] iommu: add qcom_iommu

On Tue, Mar 7, 2017 at 12:48 PM, Robin Murphy wrote: > On 01/03/17 17:42, Rob Clark wrote: >> An iommu driver for Qualcomm "B" family devices which do not completely >> implement the ARM SMMU spec. > > Is that actually true, or is it just that it's a compliant SMMU on which

Re: [PATCH 7/7] iommu/arm-smmu: add support for dynamic domains

On Tue, Mar 07, 2017 at 06:11:38PM +, Mark Rutland wrote: > On Tue, Mar 07, 2017 at 09:39:55AM -0700, Jordan Crouse wrote: > > Implement support for dynamic domain switching. This feature is > > only enabled when the qcom,dynamic device tree attribute for an smmu > > instance. > > > > In

Re: [PATCH] iommu/arm-smmu: Report smmu type in dmesg

On 07/03/17 14:06, Robert Richter wrote: > On 06.03.17 18:22:08, Robin Murphy wrote: >> On 06/03/17 13:58, Robert Richter wrote: >>> The ARM SMMU detection especially depends from system firmware. For >>> better diagnostic, log the detected type in dmesg. >> >> This paragraph especially depends

Re: [PATCH] iommu/arm-smmu: Add global SMR masking property

On Tue, Mar 07, 2017 at 06:26:28PM +, Robin Murphy wrote: > The current SMR masking support using a 2-cell iommu-specifier is > primarily intended to handle individual masters with large and/or > complex Stream ID assignments; it quickly gets a bit clunky in other SMR > use-cases where we just

[PATCH] iommu/arm-smmu: Add global SMR masking property

The current SMR masking support using a 2-cell iommu-specifier is primarily intended to handle individual masters with large and/or complex Stream ID assignments; it quickly gets a bit clunky in other SMR use-cases where we just want to consistently mask out the same part of every Stream ID (e.g.

Re: [PATCH 7/7] iommu/arm-smmu: add support for dynamic domains

On Tue, Mar 07, 2017 at 09:39:55AM -0700, Jordan Crouse wrote: > Implement support for dynamic domain switching. This feature is > only enabled when the qcom,dynamic device tree attribute for an smmu > instance. > > In order to use dynamic domains, a non-dynamic domain must first > be created and

[PATCH 4/4] iommu/arm-smmu: Use per-context TLB sync as appropriate

TLB synchronisation typically involves the SMMU blocking all incoming transactions until the TLBs report completion of all outstanding operations. In the common SMMUv2 configuration of a single distributed SMMU serving multiple peripherals, that means that a single unmap request has the potential

[PATCH 1/4] iommu/arm-smmu: Handle size mismatches better

We currently warn if the firmware-described region size differs from the SMMU address space size reported by the hardware, but continue to use the former to calculate where our context bank base should be, effectively guaranteeing that things will not work correctly. Since over-mapping is

[PATCH 0/4] ARM SMMU per-context TLB sync

The discussion around context-level access for Qualcomm SMMUs reminded me to dig up this patch I started ages ago and finish it off. As it's ended up, it's now a mini-series, with some new preparatory cleanup manifesting as patches 2 and 3. Patch 1 is broken out of patch 3 for clarity as somewhat

[PATCH 2/4] iommu/arm-smmu: Simplify ASID/VMID handling

Calculating ASIDs/VMIDs dynamically from arm_smmu_cfg was a neat trick, but the global uniqueness workaround makes it somewhat more awkward, and means we end up having to pass extra state around in certain cases just to keep a handle on the offset. We already have 16 bits going spare in

[PATCH 3/4] iommu/arm-smmu: Tidy up context bank indexing

ARM_AMMU_CB() is calculated relative to ARM_SMMU_CB_BASE(), but the latter is never of use on its own, and what we end up with is the same ARM_SMMU_CB_BASE() + ARM_AMMU_CB() expression being duplicated at every callsite. Folding the two together gives us a self-contained context bank accessor

Re: [PATCH 5/9] iommu: add qcom_iommu

On 01/03/17 17:42, Rob Clark wrote: > An iommu driver for Qualcomm "B" family devices which do not completely > implement the ARM SMMU spec. Is that actually true, or is it just that it's a compliant SMMU on which firmware has set SCR1.GASRAE? (which makes the global address space

[PATCH v5] arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU

Add support for allocating physically contiguous DMA buffers on arm64 systems with an IOMMU. This can be useful when two or more devices with different memory requirements are involved in buffer sharing. Note that as this uses the CMA allocator, setting the DMA_ATTR_FORCE_CONTIGUOUS attribute

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

On Tue, Mar 07, 2017 at 10:05:00AM -0600, Tom Lendacky wrote: > I can do that. Because phys_base hasn't been updated yet, I'll have to > create "on" and "off" constants and get their address in a similar way > to the command line option so that I can do the strncmp properly. Actually, wouldn't

Re: [Freedreno] [PATCH 0/7] RFC: iommu/arm-smmu-v2: Dynamic domains

On Tue, Mar 07, 2017 at 09:39:48AM -0700, Jordan Crouse wrote: > Pursuant to the arm-smmu-v3 SVM support: > > https://lists.linuxfoundation.org/pipermail/iommu/2017-February/020599.html > > I felt it would be helpful if I would demonstrate how Qualcomm implements > per-process pagetables for

[PATCH 3/7] iommu/arm-smmu: Add support for TTBR1

Allow a SMMU device to opt into allocating a TTBR1 pagetable. The size of the TTBR1 region will be the same as the TTBR0 size with the sign extension bit set on the highest bit in the region unless the upstream size is 49 bits and then the sign-extension bit will be set on the 49th bit. The

[PATCH 6/7] iommu: Add dynamic domains

Add an API to create a dynamic domain from an existing domain. A dynamic domain is a special IOMMU domain that is attached to the same device as the parent domain but is backed by separate pagetables. Devices such as GPUs that support asynchronous methods for switching pagetables can create

[PATCH 7/7] iommu/arm-smmu: add support for dynamic domains

Implement support for dynamic domain switching. This feature is only enabled when the qcom,dynamic device tree attribute for an smmu instance. In order to use dynamic domains, a non-dynamic domain must first be created and attached. The non-dynamic domain must remain attached while the device is

[PATCH 5/7] iommu/arm-smmu: add support for TTBR0 attribute

From: Jeremy Gebben Add support to return the value of the TTBR0 register in response to a request via DOMAIN_ATTR_TTBR0. Signed-off-by: Jeremy Gebben Signed-off-by: Jordan Crouse --- drivers/iommu/arm-smmu.c | 13

[PATCH 0/7] RFC: iommu/arm-smmu-v2: Dynamic domains

Pursuant to the arm-smmu-v3 SVM support: https://lists.linuxfoundation.org/pipermail/iommu/2017-February/020599.html I felt it would be helpful if I would demonstrate how Qualcomm implements per-process pagetables for several generations of SoCs and GPUs focusing on the Adreno A540 GPU and an

[PATCH 1/7] iommu/arm-smmu: save the pgtbl_cfg in the domain

From: Mitchel Humpherys The pgtbl_cfg object has a few handy properties that we'd like to make use of later (returning the pgd in a domain attribute, for example). Keep track of the domain pgtbl_cfg in the domain structure. Signed-off-by: Mitchel Humpherys

[PATCH 4/7] iommu: introduce TTBR0 domain attribute

From: Jeremy Gebben In the ARM SMMU architecture, pagetable programming is controlled by the TTBR0 register. The layout of this registers varies depending on the pagetable format in use. In particular, the ASID (address space ID) field is found in CONTEXTIDR when using

[PATCH 2/7] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1

Add a new domain attribute to enable the TTBR1 pagetable for drivers and devices that support it. This will enabled using a TTBR1 (otherwise known as a "global" or "system" pagetable for devices that support a split pagetable scheme for switching pagetables quickly and safely. Signed-off-by:

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

On 3/1/2017 12:40 PM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:48:25AM -0600, Tom Lendacky wrote: This patch adds the support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state).

Re: [PATCH] iommu/arm-smmu: Report smmu type in dmesg

On 06.03.17 18:22:08, Robin Murphy wrote: > On 06/03/17 13:58, Robert Richter wrote: > > The ARM SMMU detection especially depends from system firmware. For > > better diagnostic, log the detected type in dmesg. > > This paragraph especially depends from grammar. I think. Thanks for the mail on