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

2020-10-15 Thread Nicolin Chen
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 devices. > > > > > > > >

Re: [GIT PULL] dma-mapping updates for 5.10

2020-10-15 Thread pr-tracker-bot
The pull request you sent on Thu, 15 Oct 2020 19:47:43 +0200: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5a32c3413d3340f90c82c84b375ad4b335a59f28 Thank you! -- Deet-doot-dot, I am a bot.

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

2020-10-15 Thread Daniel Kiper
On Tue, Sep 29, 2020 at 10:03:47AM -0400, Ross Philipson wrote: > On 9/25/20 3:18 PM, Arvind Sankar wrote: [...] > > You should see them if you do > > readelf -r arch/x86/boot/compressed/vmlinux > > > > In terms of the code, things like: > > > > addl%ebx, (sl_gdt_desc + 2)(%ebx) > >

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

2020-10-15 Thread Raj, Ashok
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 flushing. When looking at the PCIe spec > again I noticed that most of the

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

2020-10-15 Thread Catalin Marinas
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 32 bits of DMA, in > >

[GIT PULL] dma-mapping updates for 5.10

2020-10-15 Thread Christoph Hellwig
Hi Linus, please pull the dma-mapping update for 5.10. It contains a (clean) merge of a later 5.9-rc commit, as I had to pull in a media subsystem revert that is required for later commits. There are a few trivial contextual conflicts due to the dma-mapping.h split, for those simple keep both

Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance

2020-10-15 Thread Christoph Hellwig
On Thu, Oct 15, 2020 at 05:33:34PM +0200, Daniel Vetter wrote: > On Thu, Oct 15, 2020 at 07:55:32AM +0100, Christoph Hellwig wrote: > > On Tue, Oct 13, 2020 at 02:42:38PM +0100, Robin Murphy wrote: > > > I still think this situation would be best handled with a variant of > > > dma_ops_bypass that

Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance

2020-10-15 Thread Daniel Vetter
On Thu, Oct 15, 2020 at 07:55:32AM +0100, Christoph Hellwig wrote: > On Tue, Oct 13, 2020 at 02:42:38PM +0100, Robin Murphy wrote: > > I still think this situation would be best handled with a variant of > > dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set > > automatically

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

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 22:26 +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 32 bits of DMA, in > > particular the

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

2020-10-15 Thread Hanjun Guo
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 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that

Re: [git pull] IOMMU Updates for Linux v5.10

2020-10-15 Thread Joerg Roedel
On Wed, Oct 14, 2020 at 12:15:55PM -0700, Linus Torvalds wrote: > As a result, "git show" doesn't ever really understand the notion of a > "merge conflict", and all it shows is really "whee, this end result > looks like neither side" as a kind of pseudo-conflict diff. Ah okay, that makes sense.

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

2020-10-15 Thread Lorenzo Pieralisi
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; > + acpi_status status; > + u8 limit = 32; > + int i; > + > +

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

2020-10-15 Thread Liu, Yi L
> From: Jason Wang > Sent: Thursday, October 15, 2020 4:41 PM > > > On 2020/10/15 ??3:58, Tian, Kevin wrote: > >> From: Jason Wang > >> Sent: Thursday, October 15, 2020 2:52 PM > >> > >> > >> On 2020/10/14 ??11:08, Tian, Kevin wrote: > From: Jason Wang > Sent: Tuesday, October 13,

Re: [PATCH v3 6/8] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 07:39 +0200, Christoph Hellwig wrote: > On Wed, Oct 14, 2020 at 09:12:08PM +0200, Nicolas Saenz Julienne wrote: > > + zone_dma_bits = min(zone_dma_bits, > > + (unsigned > > int)ilog2(of_dma_get_max_cpu_address(NULL))); > > Plase avoid pointlessly

Re: [PATCH v3 5/8] dma-direct: Turn zone_dma_bits default value into a define

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 07:38 +0200, Christoph Hellwig wrote: > On Wed, Oct 14, 2020 at 09:12:07PM +0200, Nicolas Saenz Julienne wrote: > > Set zone_dma_bits default value through a define so as for architectures > > to be able to override it with their default value. > > Architectures can do that

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

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 07:42 +0200, 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 device_node

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

2020-10-15 Thread Robin Murphy
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 devices. Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko Signed-off-by: Nicolin Chen --- Changelog

Re: [PATCH v3 4/8] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-10-15 Thread Nicolas Saenz Julienne
On Wed, 2020-10-14 at 17:04 -0500, Rob Herring wrote: > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > wrote: > > Introduce a test for of_dma_get_max_cup_address(), it uses the same DT > > data as the rest of dma-ranges unit tests. > > > > Signed-off-by: Nicolas Saenz Julienne > > ---

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

2020-10-15 Thread Ard Biesheuvel
On Thu, 15 Oct 2020 at 11:16, Nicolas Saenz Julienne wrote: > > On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote: > > On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote: > > > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > > > wrote: > > > > Introduce of_dma_get_max_cpu_address(),

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

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote: > On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote: > > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > > wrote: > > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU > > > physical address addressable by all

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

2020-10-15 Thread Jean-Philippe Brucker
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 faults before signaling to the device driver that it can unbind(). Add the

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

2020-10-15 Thread Jean-Philippe Brucker
Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver whether the PRI queue needs flushing. When looking at the PCIe spec again I noticed that most of the time the SMMUv3 driver doesn't actually need to flush the PRI queue. Does this make sense for Intel VT-d as well or did I

[RFC PATCH 1/2] iommu: Add flags to sva_unbind()

2020-10-15 Thread Jean-Philippe Brucker
Provide a way for device drivers to tell IOMMU drivers about the device state and the cleanup work to be done, when unbinding. No functional change. Signed-off-by: Jean-Philippe Brucker --- include/linux/intel-iommu.h | 2 +- include/linux/iommu.h | 7 --- drivers/iommu/intel/svm.c

Re: [PATCH v3 1/8] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 09:40 +0100, Will Deacon wrote: > On Wed, Oct 14, 2020 at 09:12:03PM +0200, Nicolas Saenz Julienne wrote: > > crashkernel might reserve memory located in ZONE_DMA. We plan to delay > > ZONE_DMA's initialization after unflattening the devicetree and ACPI's > > boot table

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

2020-10-15 Thread Nicolas Saenz Julienne
On Wed, 2020-10-14 at 17:02 -0500, Rob Herring wrote: > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > wrote: > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU > > physical address addressable by all DMA masters in the system. It's > > specially useful for

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

2020-10-15 Thread Jason Wang
On 2020/10/15 下午3:58, Tian, Kevin wrote: From: Jason Wang Sent: Thursday, October 15, 2020 2:52 PM On 2020/10/14 上午11:08, Tian, Kevin wrote: From: Jason Wang Sent: Tuesday, October 13, 2020 2:22 PM On 2020/10/12 下午4:38, Tian, Kevin wrote: From: Jason Wang Sent: Monday, September 14,

Re: [PATCH v3 1/8] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-10-15 Thread Will Deacon
On Wed, Oct 14, 2020 at 09:12:03PM +0200, Nicolas Saenz Julienne wrote: > crashkernel might reserve memory located in ZONE_DMA. We plan to delay > ZONE_DMA's initialization after unflattening the devicetree and ACPI's > boot table initialization, so move it later in the boot process. >

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

2020-10-15 Thread Tian, Kevin
> From: Jason Wang > Sent: Thursday, October 15, 2020 2:52 PM > > > On 2020/10/14 上午11:08, Tian, Kevin wrote: > >> From: Jason Wang > >> Sent: Tuesday, October 13, 2020 2:22 PM > >> > >> > >> On 2020/10/12 下午4:38, Tian, Kevin wrote: > From: Jason Wang > Sent: Monday, September 14,

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

2020-10-15 Thread Jason Wang
On 2020/10/15 上午7:10, Alex Williamson wrote: On Wed, 14 Oct 2020 03:08:31 + "Tian, Kevin" wrote: From: Jason Wang Sent: Tuesday, October 13, 2020 2:22 PM On 2020/10/12 下午4:38, Tian, Kevin wrote: From: Jason Wang Sent: Monday, September 14, 2020 12:20 PM [...] > If it's

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

2020-10-15 Thread Ard Biesheuvel
On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote: > > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > wrote: > > > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU > > physical address addressable by all DMA masters in the system. It's > > specially useful for

Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance

2020-10-15 Thread Christoph Hellwig
On Tue, Oct 13, 2020 at 02:42:38PM +0100, Robin Murphy wrote: > I still think this situation would be best handled with a variant of > dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set > automatically when attaching to an unmanaged IOMMU domain. dma_ops_bypass should mostly do

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

2020-10-15 Thread Jason Wang
On 2020/10/14 上午11:08, Tian, Kevin wrote: From: Jason Wang Sent: Tuesday, October 13, 2020 2:22 PM On 2020/10/12 下午4:38, Tian, Kevin wrote: From: Jason Wang Sent: Monday, September 14, 2020 12:20 PM [...] > If it's possible, I would suggest a generic uAPI instead of a VFIO specific