Re: [PATCH v12 0/7] soc: ti: Add and use PVU on K3-AM65 for DMA isolation

Manivannan Sadhasivam
2025-08-27T15:52:54Z

On Mon, Jul 28, 2025 at 10:36:54AM GMT, huaqian.li@siemens.com wrote:
> From: Li Hua Qian <huaqian.li@siemens.com>
>
> Changes in v12:
> - Fix Sparse warnings by replacing plain integer 0 with NULL for
> pointer arguments in ti_pvu_probe() (patch 3)
> (Reported-by: kernel test robot lkp@intel.com)
>
> Changes in v11:
> - Improve error handling and resolve review comments on pci-keystone
> driver (patch 4)
>
> Changes in v10:
> - Move restricted DMA initialization and cleanup to RC-specific code
> only (patch 4) as it's only needed for RC mode, not EP mode
>
> Changes in v9:
> - Update commit message (patch 4) to remove ambiguous extension claims
> based on upstream feedback
>
> Changes in v8:
> - remove patch 8 from this series to simplify the patchset
> - fix dt_bindings_check warnings (patch 2), 'memory-region' must
> not be a required property
>
> Changes in v7:
> - add schema expressing dependency as suggested on pci-host bindings
> - resolve review comments on pci-keystone driver
> - add a new patch to make IO_TLB_SEGSIZE configurable
> - improve patches based on checkpath.pl
>
> Changes in v6:
> - make restricted DMA memory-region available to all pci-keystone
> devices, moving property to unconditional section (patch 2)
>
> Changes in v5:
> - resolve review comments on pci-host bindings
> - reduce DMA memory regions to 1 - swiotlb does not support more
> - move activation into overlay (controlled via firmware)
> - use ks_init_vmap helper instead of loop in
> rework ks_init_restricted_dma
> - add more comments to pci-keystone
> - use 2 chained TLBs of PVU to support maximum of swiotlb (320 MB)
>
> Changes in v4:
> - reorder patch queue, moving all DTS changes to the back
> - limit activation to IOT2050 Advanced variants
> - move DMA pool to allow firmware-based expansion it up to 512M
>
> Changes in v3:
> - fix ti,am654-pvu.yaml according to review comments
> - address review comments on ti,am65-pci-host.yaml
> - differentiate between different compatibles in ti,am65-pci-host.yaml
> - move pvu nodes to k3-am65-main.dtsi
> - reorder patch series, pulling bindings and generic DT bits to the front
>
> Changes in v2:
> - fix dt_bindings_check issues (patch 1)
> - address first review comments (patch 2)
> - extend ti,am65-pci-host bindings for PVU (new patch 3)
>
> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system
> against DMA-based attacks of external PCI devices. The AM65 is without
> an IOMMU, but it comes with something close to it: the Peripheral
> Virtualization Unit (PVU).
>
> The PVU was originally designed to establish static compartments via a
> hypervisor, isolate those DMA-wise against each other and the host and
> even allow remapping of guest-physical addresses. But it only provides
> a static translation region, not page-granular mappings. Thus, it cannot
> be handled transparently like an IOMMU.
>
> Now, to use the PVU for the purpose of isolated PCI devices from the
> Linux host, this series takes a different approach. It defines a
> restricted-dma-pool for the PCI host, using swiotlb to map all DMA
> buffers from a static memory carve-out. And to enforce that the devices
> actually follow this, a special PVU soc driver is introduced. The driver
> permits access to the GIC ITS and otherwise waits for other drivers that
> detect devices with constrained DMA to register pools with the PVU.
>
> For the AM65, the first (and possibly only) driver where this is
> introduced is the pci-keystone host controller. Finally, this series
> provides a DT overlay for the IOT2050 Advanced devices (all have
> MiniPCIe or M.2 extension slots) to make use of this protection scheme.
> Application of this overlay will be handled by firmware.
>
> Due to the cross-cutting nature of these changes, multiple subsystems
> are affected. However, I wanted to present the whole thing in one series
> to allow everyone to review with the complete picture in hands. If
> preferred, I can also split the series up, of course.
>

How do you want the patches to be merged? I see that the PCI controller driver
has the API dependency with SoC driver. So that will go through arm-soc I
believe.

But I can take the dt-binding through PCI tree if you want. Let me know!

- Mani

--
மணிவண்ணன் சதாசிவம்