On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
Hi Andy,
[auto build test ERROR on next-20170503]
[cannot apply to pm/linux-next linus/master linux/master v4.9-rc8 v4.9-rc7
v4.9-rc6 v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andy-
On 05/03/2017 05:47 AM, Will Deacon wrote:
> Hi Geetha,
>
> On Tue, May 02, 2017 at 12:01:15PM +0530, Geetha Akula wrote:
>> SMMU_IIDR register is broken on T99, that the reason we are using MIDR.
>
> Urgh, that's unfortunate. In what way is it broken?
>
>> If using MIDR is not accepted, can we
On Thu, May 04, 2017 at 02:28:53PM -0600, Alex Williamson wrote:
> On Thu, 27 Apr 2017 18:53:17 +0800
> Peter Xu wrote:
>
> > On Wed, Apr 26, 2017 at 06:06:33PM +0800, Liu, Yi L wrote:
> > > Expose "Shared Virtual Memory" to guest by using "svm" option.
> > > Also use "svm" to expose SVM related
On Thu, 27 Apr 2017 18:53:17 +0800
Peter Xu wrote:
> On Wed, Apr 26, 2017 at 06:06:33PM +0800, Liu, Yi L wrote:
> > Expose "Shared Virtual Memory" to guest by using "svm" option.
> > Also use "svm" to expose SVM related capabilities to guest.
> > e.g. "-device intel-iommu, svm=on"
> >
> > Signed
On Thu, May 4, 2017 at 11:32 PM, Robin Murphy wrote:
> [apologies for the silence - I've been on holiday]
>
> On 03/05/17 05:46, Oza Pawandeep wrote:
>> current device framework and of framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (chi
On Thu, May 4, 2017 at 11:50 PM, Robin Murphy wrote:
> On 03/05/17 05:46, 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 0x8000 0x0 0x8000>, /* 2G @ 2G */
>> <0x
On Thu, May 4, 2017 at 11:32 PM, Robin Murphy wrote:
> [apologies for the silence - I've been on holiday]
>
> On 03/05/17 05:46, Oza Pawandeep wrote:
>> current device framework and of framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (chi
On 03/05/17 05:46, 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 0x8000 0x0 0x8000>, /* 2G @ 2G */
> <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
> <0x009
[apologies for the silence - I've been on holiday]
On 03/05/17 05:46, Oza Pawandeep wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
Well, yes, that
On Thu, May 04, 2017 at 09:34:09AM -0500, Tom Lendacky wrote:
> I masked it out here based on a previous comment from Dave Hansen:
>
> http://marc.info/?l=linux-kernel&m=148778719826905&w=2
>
> I could move the __sme_clr into the individual defines of:
Nah, it is fine as it is. I was just wond
On Thu, May 04, 2017 at 06:05:33PM +0530, Geetha sowjanya wrote:
> From: Linu Cherian
>
> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option will be enabled as an errata workaround.
>
> This option when turned on, replaces all page 1 offsets u
On May 04 2017 or thereabouts, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
On 5/4/2017 5:16 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:18:22PM -0500, Tom Lendacky wrote:
The boot data and command line data are present in memory in a decrypted
state and are copied early in the boot process. The early page fault
support will map these areas as encrypted, so b
On Thu, May 04, 2017 at 09:24:11AM -0500, Tom Lendacky wrote:
> I did this so that an the include order wouldn't cause issues (including
> asm/mem_encrypt.h followed by later by a linux/mem_encrypt.h include).
> I can make this a bit clearer by having separate #defines for each
> thing, e.g.:
>
>
On 4/27/2017 11:12 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:17:54PM -0500, Tom Lendacky wrote:
Changes to the existing page table macros will allow the SME support to
be enabled in a simple fashion with minimal changes to files that use these
macros. Since the memory encryption m
On Thu, May 4, 2017 at 8:34 AM, Rob Clark wrote:
> An iommu driver for Qualcomm "B" family devices which do not completely
> implement the ARM SMMU spec. These devices have context-bank register
> layout that is similar to ARM SMMU, but no global register space (or at
> least not one that is acce
On 4/27/2017 10:46 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:17:27PM -0500, Tom Lendacky wrote:
Add support for Secure Memory Encryption (SME). This initial support
provides a Kconfig entry to build the SME support into the kernel and
defines the memory encryption mask that will be u
On 4/27/2017 10:52 AM, Dave Hansen wrote:
On 04/27/2017 12:25 AM, Dave Young wrote:
On 04/21/17 at 02:55pm, Dave Hansen wrote:
On 04/18/2017 02:22 PM, Tom Lendacky wrote:
Add sysfs support for SME so that user-space utilities (kdump, etc.) can
determine if SME is active.
A new directory will
On 4/27/2017 2:25 AM, Dave Young wrote:
On 04/21/17 at 02:55pm, Dave Hansen wrote:
On 04/18/2017 02:22 PM, Tom Lendacky wrote:
Add sysfs support for SME so that user-space utilities (kdump, etc.) can
determine if SME is active.
A new directory will be created:
/sys/kernel/mm/sme/
And two en
On Thu, May 4, 2017 at 4:21 AM, Andy Shevchenko
wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
From: Stanimir Varbanov
This basically gets the secure page table size, allocates memory for
secure pagetables and passes the physical address to the trusted zone.
Signed-off-by: Stanimir Varbanov
Signed-off-by: Rob Clark
---
drivers/iommu/qcom_iommu.c | 64 +++
Cc: devicet...@vger.kernel.org
Signed-off-by: Rob Clark
---
.../devicetree/bindings/iommu/qcom,iommu.txt | 121 +
1 file changed, 121 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
diff --git a/Documentation/devicetree/bindings/
I want to re-use some of these for qcom_iommu, which has (roughly) the
same context-bank registers.
Signed-off-by: Rob Clark
---
drivers/iommu/arm-smmu-regs.h | 227 ++
drivers/iommu/arm-smmu.c | 203 +
2 files chan
An iommu driver for Qualcomm "B" family devices which do not completely
implement the ARM SMMU spec. These devices have context-bank register
layout that is similar to ARM SMMU, but no global register space (or at
least not one that is accessible).
Signed-off-by: Rob Clark
Signed-off-by: Stanimi
An iommu driver for Qualcomm "B" family devices which do not completely
implement the ARM SMMU spec. These devices have context-bank register
layout that is similar to ARM SMMU, but no global register space (or at
least not one that is accessible).
At this point, all the dependencies have landed
Hi Robin,
I faced same issue on our platform and debugged to get the root cause of the
issue. Also fixed in somewhat similar way, cleared iova_off and not change size
for if cookie->type is IOMMU_DMA_MSI_COOKIE. Anyways that was not as good as
below changes.
While just now I saw this was alre
From: Linu Cherian
Enable PAGE0_REGS_ONLY option for Cavium ThunderX2 SMMUv3 model.
Signed-off-by: Linu Cherian
Signed-off-by: Geetha Sowjanya
---
drivers/iommu/arm-smmu-v3.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v
From: Linu Cherian
Add Cavium ThunderX2 SMMUv3 erratas to the errata list.
Signed-off-by: Linu Cherian
Signed-off-by: Geetha Sowjanya
---
Documentation/arm64/silicon-errata.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/
From: Linu Cherian
Add SMMUv3 model definition for ThunderX2.
Signed-off-by: Linu Cherian
Signed-off-by: Geetha Sowjanya
---
include/acpi/actbl2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index faa9f2c..76a6f5d 100644
--- a/include/ac
From: Linu Cherian
Cavium ThunderX2 implementation doesn't support second page in SMMU
register space. Hence, resource size is set as 64k for this model.
Signed-off-by: Linu Cherian
Signed-off-by: Geetha Sowjanya
---
drivers/acpi/arm64/iort.c | 10 +-
1 file changed, 9 insertions(+),
From: Geetha Sowjanya
Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq
lines for gerror, eventq and cmdq-sync.
This patch addresses the issue by checking if any interrupt sources are
using same irq number, then they are registered as shared irqs.
Signed-off-by: Geetha
From: Linu Cherian
With implementations supporting only page 0 register space,
resource size can be 64k as well and hence perform size checks
based on SMMU option PAGE0_REGS_ONLY.
For this, arm_smmu_device_dt_probe/acpi_probe has been moved before
platform_get_resource call, so that SMMU options
From: Linu Cherian
Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
and PAGE0_REGS_ONLY option will be enabled as an errata workaround.
This option when turned on, replaces all page 1 offsets used for
EVTQ_PROD/CONS, PRIQ_PROD/CONS register access with page 0 offsets.
From: Linu Cherian
Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
1. Errata ID #74
SMMU register alias Page 1 is not implemented
2. Errata ID #126
SMMU doesnt support unique IRQ lines and also MSI for gerror,
eventq and cmdq-sync
The following patchset does software wo
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index cbf7763d8091..420d51b286ad 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1808,10 +1808,9 @@ IOMMU_INIT_POST(detect_intel_iommu);
> * for Dir
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and
On Tue, Apr 18, 2017 at 04:18:22PM -0500, Tom Lendacky wrote:
> The boot data and command line data are present in memory in a decrypted
> state and are copied early in the boot process. The early page fault
> support will map these areas as encrypted, so before attempting to copy
> them, add decr
On Thu, 04 May 2017, Andy Shevchenko wrote:
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c
> b/drivers/gpu/drm/i915/intel_acpi.c
> index eb638a1e69d2..72bfe6ceadf8 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -15,13 +15,9 @@ static struct intel
acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use uuid_le type. At the same time we
convert current users.
acpi_str_to_uuid() becomes useless after the conversion and it's safe to
get rid of it.
The conversion fixes a potential bug in int34
40 matches
Mail list logo
