On Mon, Jul 28, 2025 at 10:36:54AM GMT, huaqian.li@xxxxxxxxxxx wrote: > From: Li Hua Qian <huaqian.li@xxxxxxxxxxx> > > 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@xxxxxxxxx) > > 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 -- மணிவண்ணன் சதாசிவம்
