> From: Jean-Philippe Brucker
> Sent: Monday, July 26, 2021 4:15 PM
>
> Hi Kevin,
>
> On Fri, Jul 09, 2021 at 07:48:44AM +, Tian, Kevin wrote:
> > /dev/iommu provides an unified interface for managing I/O page tables for
> > devices assigned to userspace. Device passthrough frameworks
Hi, David,
> From: David Gibson
> Sent: Monday, July 26, 2021 12:51 PM
>
> On Fri, Jul 09, 2021 at 07:48:44AM +, Tian, Kevin wrote:
> > /dev/iommu provides an unified interface for managing I/O page tables for
> > devices assigned to userspace. Device passthrough frameworks (VFIO,
> vDPA,
>
On Mon, Jul 26, 2021 at 3:51 PM John Garry wrote:
>
> On 23/07/2021 11:21, Ming Lei wrote:
> >> Thanks, I was also going to suggest the latter, since it's what
> >> arm_smmu_cmdq_issue_cmdlist() does with IRQs masked that should be most
> >> indicative of where the slowness most likely stems
On 7/27/21 5:26 PM, Tom Lendacky wrote:
> This patch series provides a generic helper function, prot_guest_has(),
> to replace the sme_active(), sev_active(), sev_es_active() and
> mem_encrypt_active() functions.
>
> It is expected that as new protected virtualization technologies are
> added to
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation. Since the default implementation of the
prot_guest_has() matches the s390 implementation of mem_encrypt_active(),
prot_guest_has() does not need to be implemented in s390 (the config
option
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Tom Lendacky
---
arch/powerpc/include/asm/mem_encrypt.h | 5 -
1 file changed, 5 deletions(-)
diff
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h | 5 -
1 file changed, 5 deletions(-)
diff --git
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation.
Signed-off-by: Tom Lendacky
---
include/linux/mem_encrypt.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index
Replace occurrences of mem_encrypt_active() with calls to prot_guest_has()
with the PATTR_MEM_ENCRYPT attribute.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc:
Replace occurrences of sev_es_active() with the more generic
prot_guest_has() using PATTR_GUEST_PROT_STATE, except for in
arch/x86/kernel/sev*.c and arch/x86/mm/mem_encrypt*.c where PATTR_SEV_ES
will be used. If future support is added for other memory encyrption
techonologies, the use of
Replace occurrences of sev_active() with the more generic prot_guest_has()
using PATTR_GUEST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c
where PATTR_SEV will be used. If future support is added for other memory
encryption technologies, the use of PATTR_GUEST_MEM_ENCRYPT can be
updated,
Replace occurrences of sme_active() with the more generic prot_guest_has()
using PATTR_HOST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c
where PATTR_SME will be used. If future support is added for other memory
encryption technologies, the use of PATTR_HOST_MEM_ENCRYPT can be
updated, as
Introduce a powerpc version of the prot_guest_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only support the PATTR_MEM_ENCRYPT
attribute.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Introduce an x86 version of the prot_guest_has() function. This will be
used in the more generic x86 code to replace vendor specific calls like
sev_active(), etc.
While the name suggests this is intended mainly for guests, it will
also be used for host memory encryption checks in place of
In prep for other protected virtualization technologies, introduce a
generic helper function, prot_guest_has(), that can be used to check
for specific protection attributes, like memory encryption. This is
intended to eliminate having to add multiple technology-specific checks
to the code (e.g. if
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to the kernel, they can all be covered by a single
On 2021-07-23 11:21, Ming Lei wrote:
On Thu, Jul 22, 2021 at 06:40:18PM +0100, Robin Murphy wrote:
On 2021-07-22 16:54, Ming Lei wrote:
[...]
If you are still keen to investigate more, then can try either of these:
- add iommu.strict=0 to the cmdline
- use perf record+annotate to find the
On 2021-07-27 15:05, Zhou, Peng Ju wrote:
[AMD Official Use Only]
Hi Robin
The patch which add "head" :
commit 48a64dd561a53fb809e3f2210faf5dd442cfc56d
Author: Chris Wilson
Date: Sat Jan 16 11:10:35 2021 +
iommu/iova: Use bottom-up allocation for DMA32
Since DMA32
[AMD Official Use Only]
Hi Robin
The patch which add "head" :
commit 48a64dd561a53fb809e3f2210faf5dd442cfc56d
Author: Chris Wilson
Date: Sat Jan 16 11:10:35 2021 +
iommu/iova: Use bottom-up allocation for DMA32
Since DMA32 allocations are currently allocated top-down from the 4G
On 2021-07-27 13:14, Bixuan Cui wrote:
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is powered off and the registers are
cleared. So saves the msi_msg context during msi interrupt initialization
of smmu. When resume happens it calls
On 27.07.21 14:57, Will Deacon wrote:
On Tue, Jul 27, 2021 at 02:54:14PM +0200, Christian Borntraeger wrote:
On 24.07.21 02:27, Konrad Rzeszutek Wilk wrote:
On Sat, Jul 24, 2021 at 01:17:46AM +0200, Halil Pasic wrote:
Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
On Tue, 27 Jul 2021 13:14:08 +0100,
Bixuan Cui wrote:
>
> Add suspend and resume support for arm-smmu-v3 by low-power mode.
>
> When the smmu is suspended, it is powered off and the registers are
> cleared. So saves the msi_msg context during msi interrupt initialization
> of smmu. When resume
On Tue, Jul 27, 2021 at 02:54:14PM +0200, Christian Borntraeger wrote:
>
> On 24.07.21 02:27, Konrad Rzeszutek Wilk wrote:
> > On Sat, Jul 24, 2021 at 01:17:46AM +0200, Halil Pasic wrote:
> > > Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
> > > swiotlb data bouncing") if
On 24.07.21 02:27, Konrad Rzeszutek Wilk wrote:
On Sat, Jul 24, 2021 at 01:17:46AM +0200, Halil Pasic wrote:
Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
swiotlb data bouncing") if code sets swiotlb_force it needs to do so
before the swiotlb is initialised. Otherwise
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is powered off and the registers are
cleared. So saves the msi_msg context during msi interrupt initialization
of smmu. When resume happens it calls arm_smmu_device_reset() to restore
the registers.
Hi Robin,
On 2021-07-27 16:03, Robin Murphy wrote:
On 2021-07-27 11:25, Robin Murphy wrote:
On 2021-07-27 10:33, Sai Prakash Ranjan wrote:
Some clocks for SMMU can have parent as XO such as
gpu_cc_hub_cx_int_clk
of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states
in
such
On 2021-07-27 11:25, Robin Murphy wrote:
On 2021-07-27 10:33, Sai Prakash Ranjan wrote:
Some clocks for SMMU can have parent as XO such as gpu_cc_hub_cx_int_clk
of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states in
such cases, we would need to drop the XO clock vote in
On 2021-07-27 10:33, Sai Prakash Ranjan wrote:
Some clocks for SMMU can have parent as XO such as gpu_cc_hub_cx_int_clk
of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states in
such cases, we would need to drop the XO clock vote in unprepare call and
this unprepare callback for
Some clocks for SMMU can have parent as XO such as gpu_cc_hub_cx_int_clk
of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states in
such cases, we would need to drop the XO clock vote in unprepare call and
this unprepare callback for XO is in RPMh (Resource Power Manager-Hardened)
On Mon, Jul 26, 2021 at 03:47:54PM -0700, Atish Patra wrote:
> arch_dma_set_uncached works as well in this case. However, mips,
> niops2 & xtensa uses a
> fixed (via config) value for the offset. Similar approach can't be
> used here because the platform specific
> offset value has to be
On 2021-07-27 05:46, Zhou, Peng Ju wrote:
[AMD Official Use Only]
Hi Robin
1. it is not a good manner to free a statically allocated object(in this case, it
is iovad->head) dynamically even though the free only occurred when shut down
the OS in most cases.
2. the kmemleak occurred when
On 2021/7/16 16:34, Shameer Kolothum wrote:
Hi,
Major Changes from v5:
- Addressed comments from Robin & Lorenzo.
: Moved iort_parse_rmr() to acpi_iort_init() from
iort_init_platform_devices().
: Removed use of struct iort_rmr_entry during the initial
parse. Using struct
> -Original Message-
> From: Laurentiu Tudor [mailto:laurentiu.tu...@nxp.com]
> Sent: 19 July 2021 14:46
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: j...@solid-run.com; Linuxarm ;
>
33 matches
Mail list logo
