Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-16 Thread Hanjun Guo
Hi Ard, On 2020/10/16 14:54, Ard Biesheuvel wrote: On Fri, 16 Oct 2020 at 08:51, Hanjun Guo wrote: On 2020/10/16 2:03, Catalin Marinas wrote: On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote: On 2020/10/15 3:12, Nicolas Saenz Julienne wrote: From: Ard Biesheuvel We recently

Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-16 Thread Hanjun Guo
On 2020/10/16 15:27, Hanjun Guo wrote: The patch only takes the address limit field into account if its value > 0. Sorry I missed the if (*->memory_address_limit) check, thanks for the reminding. Also, before commit 7fb89e1d44cb6aec ("ACPI/IORT: take _DMA methods into account for named

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

2020-10-16 Thread Jean-Philippe Brucker
On Thu, Oct 15, 2020 at 11:22:11AM -0700, Raj, Ashok wrote: > Hi Jean > > + Baolu who is looking into this. > > > On Thu, Oct 15, 2020 at 11:00:27AM +0200, Jean-Philippe Brucker wrote: > > Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver > > whether the PRI queue needs

Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-16 Thread Rob Herring
On Thu, Oct 15, 2020 at 12:42 AM Christoph Hellwig wrote: > > > +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np) > > +{ > > + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX; > > + struct of_range_parser parser; > > + phys_addr_t subtree_max_addr; > > + struct

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

2020-10-16 Thread Robin Murphy
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, Robin Murphy wrote: On 2020-10-09 17:19, Nicolin Chen wrote: This patch simply adds support for PCI

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

2020-10-16 Thread Jason Gunthorpe
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 are OK with this direction and more discussions > are possibly required for the new /dev/ioasid interface. Internally >

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

2020-10-16 Thread Arvind Sankar
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.: > > arch/x86/boot/compressed/vmlinux.lds.S: >

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

2020-10-16 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 v4 1/3] iommu/arm-smmu: Allow implementation specific write_s2cr

2020-10-16 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 v4 0/3] iommu/arm-smmu-qcom: Support maintaining bootloader mappings

2020-10-16 Thread Bjorn Andersson
This is the 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 context

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

2020-10-16 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 v7 3/3] iommu/tegra-smmu: Add PCI support

2020-10-16 Thread Nicolin Chen
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, Robin Murphy wrote: > > > > >

Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-16 Thread Hanjun Guo
On 2020/10/16 2:03, Catalin Marinas wrote: On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote: On 2020/10/15 3:12, Nicolas Saenz Julienne wrote: From: Ard Biesheuvel We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than

Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-16 Thread Ard Biesheuvel
On Fri, 16 Oct 2020 at 08:51, Hanjun Guo wrote: > > On 2020/10/16 2:03, Catalin Marinas wrote: > > On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote: > >> On 2020/10/15 3:12, Nicolas Saenz Julienne wrote: > >>> From: Ard Biesheuvel > >>> > >>> We recently introduced a 1 GB sized

Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-16 Thread Ard Biesheuvel
On Thu, 15 Oct 2020 at 12:31, Lorenzo Pieralisi wrote: > > On Wed, Oct 14, 2020 at 09:12:09PM +0200, Nicolas Saenz Julienne wrote: > > [...] > > > +unsigned int __init acpi_iort_get_zone_dma_size(void) > > +{ > > + struct acpi_table_iort *iort; > > + struct acpi_iort_node *node, *end; > >

Re: [RFC PATCH 2/2] iommu: Add IOMMU_UNBIND_FAULT_PENDING flag

2020-10-16 Thread Christoph Hellwig
On Thu, Oct 15, 2020 at 11:00:29AM +0200, Jean-Philippe Brucker wrote: > IOMMU drivers only need to flush their PRI queue when faults might be > pending. According to the PCIe spec (quoted below) this only happens > when using the "Stop Marker" method. Otherwise the function waits for > pending