Announcement

Collapse
No announcement yet.

AMD Closing In On IOMMU SVA Support For Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD Closing In On IOMMU SVA Support For Linux

    Phoronix: AMD Closing In On IOMMU SVA Support For Linux

    The IOMMU changes for Linux 6.7 aren't particularly noteworthy besides adding SMMUv2 support for the Qualcomm SDM670 and SM7150 SoCs. But the IOMMU updates also take the kernel one step away from supporting Shared Virtual Addressing (SVA) on AMD platforms in the near future...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    FWIW, AMD had this in the IOMMU driver for years (it was the IOMMUv2 code). It was left as an AMD specific interface because at the time it was added only radeon and amdgpu used it and at the time no other IOMMU vendors wanted to support it as a generic API. Since then, the SVA API was added which provides the same functionality. As such the AMD specific IOMMUv2 interfaces are now getting removed and replaced with the SVA interfaces. Ultimately, it's the same functionality (ATS/PASID/PRI) exposed in both APIs.

    Comment


    • #3
      There's an XKCD standards joke somewhere in that post.

      Comment


      • #4
        I hope things become better in IOMMU, specially for consumer hardware.

        Comment


        • #5
          Originally posted by agd5f View Post
          FWIW, AMD had this in the IOMMU driver for years (it was the IOMMUv2 code). It was left as an AMD specific interface because at the time it was added only radeon and amdgpu used it and at the time no other IOMMU vendors wanted to support it as a generic API. Since then, the SVA API was added which provides the same functionality. As such the AMD specific IOMMUv2 interfaces are now getting removed and replaced with the SVA interfaces. Ultimately, it's the same functionality (ATS/PASID/PRI) exposed in both APIs.
          Given there's at least a theoretical chance of data leakage in any shared resource architecture between programs that share those resources, are there any security considerations that need to be made to keep data private on systems utilizing SVA or the now to be removed IOMMUv2 to prevent handing programmers a foot gun? Serious question. I'm not looking for "write it in Rust" answers, but rather a logical & practical approach to making sure any foot guns have no bullets.

          Comment


          • #6
            Originally posted by stormcrow View Post

            Given there's at least a theoretical chance of data leakage in any shared resource architecture between programs that share those resources, are there any security considerations that need to be made to keep data private on systems utilizing SVA or the now to be removed IOMMUv2 to prevent handing programmers a foot gun? Serious question. I'm not looking for "write it in Rust" answers, but rather a logical & practical approach to making sure any foot guns have no bullets.
            This is more about providing a shared virtual address space in userspace for the CPU and devices. E.g., pointer is a pointer. Devices that support the PCI PRI/PASID extensions can use a shared page table for both the CPU and the device. PRI also allows for device page faults so device access access to memory should be pretty much identical to the CPU.

            Comment

            Working...
            X