> From: Jean-Philippe Brucker
> Sent: Tuesday, February 28, 2017 3:55 AM
>
[...]
>
> API naming
> ==
>
> I realize that "SVM" as a name isn't great because the svm namespace is
> already taken by AMD-V (Secure Virtual Machine) in arch/x86. Also, the
> name itself doesn't say much.
>
Hi Robin/Will,
This patch is currently not applied on the tree.
I had verified the patch and it seems good.
Is ack required on the patch or do I need to send a non RFC patch (with Robin's
signoff)?
This is very much required to support SMMU on NXP platform.
Thanks,
Nipun
> -Original Messa
On Wed, Mar 1, 2017 at 6:54 PM, Stephen Boyd wrote:
> On 03/01/2017 09:42 AM, Rob Clark wrote:
>> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
>> new file mode 100644
>> index 000..5d3bb63
>> --- /dev/null
>> +++ b/drivers/iommu/qcom_iommu.c
>> @@ -0,0 +1,825 @@
>> +/*
On 03/01/2017 09:42 AM, Rob Clark wrote:
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> new file mode 100644
> index 000..5d3bb63
> --- /dev/null
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -0,0 +1,825 @@
> +/*
> + * IOMMU API for QCOM secure IOMMUs. Somewhat based on arm
On 03/01/2017 09:42 AM, Rob Clark wrote:
> From: Stanimir Varbanov
>
> This bassicaly get the secure page table size, allocate memory
s/bassicaly/basically/
s/get/gets/
s/allocate/allocates/
Heh, bass.
> and return back the physical address to the trusted zone.
s/return/returns/
>
> Signed-of
On Wed, Mar 01, 2017 at 04:09:38PM -0500, Konrad Rzeszutek Wilk wrote:
> .snip..
> >
> > No. SVM is purely about sharing CPU address space with device. Command
> > submission is still through kernel driver which controls rings (with SVM
> > then
> > you can put VA into those commands). There are
.snip..
> > > Shared Virtual Memory feature in pass-through scenarios is actually SVM
> > > virtualization. It is to let application programs(running in guest)share
> > > their
> > > virtual address with assigned device(e.g. graphics processors or
> > > accelerators).
> >
> > I think I am missin
On 2/27/2017 2:54 PM, Jean-Philippe Brucker wrote:
> /* Initialise command lazily */
> + if (!cmd.opcode)
> + arm_smmu_atc_invalidate_to_cmd(smmu, iova, size, &cmd);
> +
> + spin_lock(&smmu_group->devices_lock);
> +
> + list_for_each_entry(mas
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). If memory encryption
> is to be activated
On 3/1/2017 3:17 AM, Dave Young wrote:
Hi Tom,
Hi Dave,
... SNIP ...
- Added support for (re)booting with kexec
Could you please add kexec list in cc when you updating the patches so
that kexec/kdump people do not miss them?
Sorry about that, I'll be sure to add it to the cc list.
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 57 +++
1 file changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 7bcf4cd..10ca05a 100644
--- a/arch/arm64/boot/dts/qcom/m
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 68a8e67..b0daf39 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
From: Stanimir Varbanov
Signed-off-by: Stanimir Varbanov
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index b0d
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
---
drivers/iommu/Kco
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm-32.c | 6 ++
drivers/firmware/qcom_scm-64.c | 16
drivers/firmware/qcom_scm.c| 6 ++
drivers/firmware/qcom_scm.h| 5 +
include/linux/qcom_scm.h | 2 ++
5 files changed, 35 insertions(+)
diff --g
From: Stanimir Varbanov
This bassicaly get the secure page table size, allocate memory
and return back the physical address to the trusted zone.
Signed-off-by: Stanimir Varbanov
Signed-off-by: Rob Clark
---
drivers/iommu/qcom_iommu.c | 64 ++
1 file
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 | 225 ++
drivers/iommu/arm-smmu.c | 200 +
2 files chan
Cc: devicet...@vger.kernel.org
Signed-off-by: Rob Clark
---
.../devicetree/bindings/iommu/qcom,iommu.txt | 106 +
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
diff --git a/Documentation/devicetree/bindings/
From: Stanimir Varbanov
Those two new SCM calls are needed from qcom-iommu driver in order
to initialize secure iommu page table.
Signed-off-by: Stanimir Varbanov
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm-64.c | 42 ++
drivers/firmware/qcom
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).
Compared to first version of the patchset, the b
On Thu, Feb 16, 2017 at 09:48:08AM -0600, Tom Lendacky wrote:
> This patch adds the support to encrypt the kernel in-place. This is
> done by creating new page mappings for the kernel - a decrypted
> write-protected mapping and an encrypted mapping. The kernel is encyrpted
s/encyrpted/encrypted/
+kexec list
On 2/28/2017 4:35 AM, Borislav Petkov wrote:
On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
Provide support so that kexec can be used to boot a kernel when SME is
enabled.
Support is needed to allocate pages for kexec without encryption. This
is needed in order to b
On Tue, Feb 28, 2017 at 05:28:48PM -0600, Tom Lendacky wrote:
> That's a good idea, I'll expand on that. I probably won't be that
> direct in my comment though :)
You either haven't dealt with firmware long enough or you're much better
person than me. :-)))
--
Regards/Gruss,
Boris.
Good ma
On Tue, Feb 28, 2017 at 05:19:51PM -0600, Tom Lendacky wrote:
> Device drivers don't supply set_dma_mask() since that is part of the
> dma_map_ops structure. The fm10k_pf.c file function is unrelated to this
> (it's part of an internal driver structure). The dma_map_ops structure
> is setup by the
On Wed, Mar 01, 2017 at 08:19:30AM +0800, kbuild test robot wrote:
> >> include/linux/intel-iommu.h:457:52: error: 'struct iommu_device' has no
> >> member named 'dev'
> return container_of(dev, struct intel_iommu, iommu.dev);
Yeah, I noticed that issue too and fixed it before sending the
pu
Add kexec list..
On 03/01/17 at 05:25pm, Dave Young wrote:
> Hi Tom,
>
> On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > > Provide support so that kexec can be used to boot
Hi Tom,
On 02/17/17 at 10:43am, Tom Lendacky wrote:
> On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > Provide support so that kexec can be used to boot a kernel when SME is
> > > enabled.
> >
> > Is the point of kexec and
Hi Tom,
On 02/16/17 at 09:41am, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be aut
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, February 28, 2017 11:23 PM
>
> Hi Kevin,
>
> On Tue, Feb 28, 2017 at 06:43:31AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Tuesday, February 28, 2017 11:54 AM
> > >
> > > On Mon, 27 Feb 20
29 matches
Mail list logo
