RE: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-19 Thread Liu, Yi L
Hi Jason, Good to see your response. > From: Jason Gunthorpe > Sent: Friday, October 16, 2020 11:37 PM > > On Wed, Oct 14, 2020 at 03:16:22AM +, Tian, Kevin wrote: > > Hi, Alex and Jason (G), > > > > How about your opinion for this new proposal? For now looks both > > Jason (W) and Jean

Re: [PATCH v7 3/3] iommu/tegra-smmu: Add PCI support

2020-10-19 Thread Robin Murphy
On 2020-10-17 02:56, Nicolin Chen wrote: On Fri, Oct 16, 2020 at 03:10:26PM +0100, Robin Murphy wrote: On 2020-10-16 04:53, Nicolin Chen wrote: On Thu, Oct 15, 2020 at 10:55:52AM +0100, Robin Murphy wrote: On 2020-10-15 05:13, Nicolin Chen wrote: On Wed, Oct 14, 2020 at 06:42:36PM +0100,

Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built

2020-10-19 Thread Joerg Roedel
On Tue, Oct 13, 2020 at 09:30:55AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Since commit c40c1018 ("iommu/vt-d: Gracefully handle DMAR units > with no supported address widths") dmar.c needs struct iommu_device to > be selected. We can drop this dependency by not

[PATCH 1/4] iommu: Introduce iotlb_sync_range callback

2020-10-19 Thread Chao Hao
Add iotlb_sync_range callback to support that driver can appoint iova and size to do tlb sync. Iommu will call iotlb_sync_range() after the whole mapping/unmapping is completed, and the iova and size of iotlb_sync_range() are start_iova and buffer total_size respectively. At the same time,

[PATCH 2/4] iommu/mediatek: Add iotlb_sync_range() support

2020-10-19 Thread Chao Hao
MTK_IOMMU driver writes one page entry and does tlb flush at a time currently. More optimal would be to aggregate the writes and flush BUS buffer in the end. For 50MB buffer mapping, if mtk_iommu driver use iotlb_sync_range() instead of tlb_add_range() and tlb_flush_walk/leaf(), it can increase

[PATCH 0/4] MTK_IOMMU: Optimize mapping / unmapping performance

2020-10-19 Thread Chao Hao
For MTK platforms, mtk_iommu is using iotlb_sync(), tlb_add_range() and tlb_flush_walk/leaf() to do tlb sync when iommu driver runs iova mapping/unmapping. But if buffer size is large, it maybe consist of many pages(4K/8K/64K/1MB..). So iommu driver maybe run many times tlb sync in

[PATCH 4/4] iommu/mediatek: Adjust iotlb_sync_range

2020-10-19 Thread Chao Hao
As is title, the patch only adjusts the architecture of iotlb_sync_range(). No functional change. Signed-off-by: Chao Hao --- drivers/iommu/mtk_iommu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c

[PATCH 3/4] iommu/mediatek: Remove unnecessary tlb sync

2020-10-19 Thread Chao Hao
As is "[PATCH 2/4]" described, we will use iotlb_sync_range() to replace iotlb_sync(), tlb_add_range() and tlb_flush_walk/leaf() to enhance performance. So we will remove the implementation of iotlb_sync(), tlb_add_range() and tlb_flush_walk/leaf(). Signed-off-by: Chao Hao ---

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

2020-10-19 Thread Denis Odintsov
Hi, 2) Second issue I got (btw I have ClearFog GT 8k armada-8040 based board) is mpci ath10k card. It is found, it is enumerated, it is visible in lspci, but it fails to be initialised. Here is the log: [1.743754] armada8k-pcie f260.pcie: host bridge /cp0/pcie@f260 ranges: [

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-19 Thread Jean-Philippe Brucker
On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote: > > For devices that *don't* use a stop marker, the PCIe spec says (10.4.1.2): > > > > To stop [using a PASID] without using a Stop Marker Message, the > > function shall: > > 1. Stop queueing new Page Request Messages for this

Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub

2020-10-19 Thread Daniel Kiper
On Fri, Oct 16, 2020 at 04:51:51PM -0400, Arvind Sankar wrote: > On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote: > > > > I am discussing with Ross the other option. We can create > > .rodata.mle_header section and put it at fixed offset as > > kernel_info is. So, we would have, e.g.:

Re: [PATCH v4 3/3] iommu/arm-smmu-qcom: Implement S2CR quirk

2020-10-19 Thread Robin Murphy
On 2020-10-17 05:39, Bjorn Andersson wrote: The firmware found in some Qualcomm platforms intercepts writes to S2CR in order to replace bypass type streams with fault; and ignore S2CR updates of type fault. Detect this behavior and implement a custom write_s2cr function in order to trick the

Re: [PATCH v4 2/3] iommu/arm-smmu-qcom: Read back stream mappings

2020-10-19 Thread Robin Murphy
On 2020-10-17 05:39, Bjorn Andersson wrote: The Qualcomm boot loader configures stream mapping for the peripherals that it accesses and in particular it sets up the stream mapping for the display controller to be allowed to scan out a splash screen or EFI framebuffer. Read back the stream

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-19 Thread Jason Gunthorpe
On Mon, Oct 19, 2020 at 08:39:03AM +, Liu, Yi L wrote: > Hi Jason, > > Good to see your response. Ah, I was away > > > > Second, IOMMU nested translation is a per IOMMU domain > > > > capability. Since IOMMU domains are managed by VFIO/VDPA > > > > (alloc/free domain, attach/detach device,

Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub

2020-10-19 Thread Ross Philipson
On 10/16/20 4:51 PM, Arvind Sankar wrote: > On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote: >> >> I am discussing with Ross the other option. We can create >> .rodata.mle_header section and put it at fixed offset as >> kernel_info is. So, we would have, e.g.: >> >>

Re: [PATCH v4 2/3] iommu/arm-smmu-qcom: Read back stream mappings

2020-10-19 Thread Bjorn Andersson
On Mon 19 Oct 09:03 CDT 2020, Robin Murphy wrote: > On 2020-10-17 05:39, Bjorn Andersson wrote: > > The Qualcomm boot loader configures stream mapping for the peripherals > > that it accesses and in particular it sets up the stream mapping for the > > display controller to be allowed to scan out

Re: [PATCH v4 1/3] iommu/arm-smmu: Allow implementation specific write_s2cr

2020-10-19 Thread Robin Murphy
On 2020-10-17 05:39, Bjorn Andersson wrote: The firmware found in some Qualcomm platforms intercepts writes to the S2CR register in order to replace the BYPASS type with FAULT. Further more it treats faults at this level as catastrophic and restarts the device. Add support for providing

[git pull] IOMMU Fixes for Linux since iommu-updates-v5.10

2020-10-19 Thread Joerg Roedel
Hi Linus, The following changes since commit 7e3c3883c381aeda903778d7e99fc4cd523be610: Merge branches 'arm/allwinner', 'arm/mediatek', 'arm/renesas', 'arm/tegra', 'arm/qcom', 'arm/smmu', 'ppc/pamu', 'x86/amd', 'x86/vt-d' and 'core' into next (2020-10-07 11:51:59 +0200) are available in the

[PATCH v5 3/3] iommu/arm-smmu-qcom: Implement S2CR quirk

2020-10-19 Thread Bjorn Andersson
The firmware found in some Qualcomm platforms intercepts writes to S2CR in order to replace bypass type streams with fault; and ignore S2CR updates of type fault. Detect this behavior and implement a custom write_s2cr function in order to trick the firmware into supporting bypass streams by the

Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub

2020-10-19 Thread Arvind Sankar
On Mon, Oct 19, 2020 at 04:51:53PM +0200, Daniel Kiper wrote: > On Fri, Oct 16, 2020 at 04:51:51PM -0400, Arvind Sankar wrote: > > On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote: > > > > > > I am discussing with Ross the other option. We can create > > > .rodata.mle_header section

Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub

2020-10-19 Thread Arvind Sankar
On Mon, Oct 19, 2020 at 10:38:08AM -0400, Ross Philipson wrote: > On 10/16/20 4:51 PM, Arvind Sankar wrote: > > On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote: > >> > >> I am discussing with Ross the other option. We can create > >> .rodata.mle_header section and put it at fixed

Re: [PATCH v4 3/3] iommu/arm-smmu-qcom: Implement S2CR quirk

2020-10-19 Thread Bjorn Andersson
On Mon 19 Oct 09:04 CDT 2020, Robin Murphy wrote: > On 2020-10-17 05:39, Bjorn Andersson wrote: > > The firmware found in some Qualcomm platforms intercepts writes to S2CR > > in order to replace bypass type streams with fault; and ignore S2CR > > updates of type fault. > > > > Detect this

[PATCH v5 2/3] iommu/arm-smmu-qcom: Read back stream mappings

2020-10-19 Thread Bjorn Andersson
The Qualcomm boot loader configures stream mapping for the peripherals that it accesses and in particular it sets up the stream mapping for the display controller to be allowed to scan out a splash screen or EFI framebuffer. Read back the stream mappings during initialization and make the

[PATCH v5 1/3] iommu/arm-smmu: Allow implementation specific write_s2cr

2020-10-19 Thread Bjorn Andersson
The firmware found in some Qualcomm platforms intercepts writes to the S2CR register in order to replace the BYPASS type with FAULT. Further more it treats faults at this level as catastrophic and restarts the device. Add support for providing implementation specific versions of the S2CR write

[PATCH v5 0/3] iommu/arm-smmu-qcom: Support maintaining bootloader mappings

2020-10-19 Thread Bjorn Andersson
This is the revised fourth attempt of inheriting the stream mapping for the framebuffer on many Qualcomm platforms, in order to not hit catastrophic faults during arm-smmu initialization. The new approach does, based on Robin's suggestion, take a much more direct approach with the allocation of a

Re: [PATCH v3 00/14] IOASID extensions for guest SVA

2020-10-19 Thread Jacob Pan
Hi, Any comments on this? I know we have some opens w.r.t. PASID management UAPI, but I think having this common kernel API features should be justified. Thanks! Jacob On Mon, 28 Sep 2020 14:38:27 -0700, Jacob Pan wrote: > IOASID was introduced in v5.5 as a generic kernel allocator service

Re: [PATCH v5 2/3] iommu/arm-smmu-qcom: Read back stream mappings

2020-10-19 Thread Robin Murphy
On 2020-10-19 19:23, Bjorn Andersson wrote: The Qualcomm boot loader configures stream mapping for the peripherals that it accesses and in particular it sets up the stream mapping for the display controller to be allowed to scan out a splash screen or EFI framebuffer. Read back the stream

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-19 Thread Jacob Pan
Hi Jean-Philippe, On Mon, 19 Oct 2020 16:08:24 +0200, Jean-Philippe Brucker wrote: > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote: > > > For devices that *don't* use a stop marker, the PCIe spec says > > > (10.4.1.2): > > > > > > To stop [using a PASID] without using a Stop

Re: [PATCH v5 3/3] iommu/arm-smmu-qcom: Implement S2CR quirk

2020-10-19 Thread Robin Murphy
On 2020-10-19 19:23, Bjorn Andersson wrote: The firmware found in some Qualcomm platforms intercepts writes to S2CR in order to replace bypass type streams with fault; and ignore S2CR updates of type fault. Detect this behavior and implement a custom write_s2cr function in order to trick the

Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub

2020-10-19 Thread Ross Philipson
On 10/19/20 1:06 PM, Arvind Sankar wrote: > On Mon, Oct 19, 2020 at 10:38:08AM -0400, Ross Philipson wrote: >> On 10/16/20 4:51 PM, Arvind Sankar wrote: >>> On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote: I am discussing with Ross the other option. We can create

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-19 Thread Raj, Ashok
Hi Jean On Mon, Oct 19, 2020 at 04:08:24PM +0200, Jean-Philippe Brucker wrote: > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote: > > > For devices that *don't* use a stop marker, the PCIe spec says (10.4.1.2): > > > > > > To stop [using a PASID] without using a Stop Marker Message,