Re: [XEN RFC PATCH v5 3/5] xen/public: Introduce PV-IOMMU hypercall interface

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 4 Feb 2025, Julien Grall wrote:
> On Tue, 4 Feb 2025 at 11:46, Teddy Astie <teddy.astie@xxxxxxxxxx> wrote:
>       If the hardware supports it, there is a alternative (still being
>       drafted) interface to allow the guest to directly provide native 
> pagetables.
> 
>       This is exposed through the "_nested" subcommands, there is no
>       implementation of this feature in this patch series yet.
> 
> 
> Out of interest, if the HW support two stage translations, then why do we 
> need a PV interface? Wouldn’t it be better to exposed an emulated
> iommu? This would reduce the amount of enlightenment required in the guest 
> OS. In the long run, this would provide some better performance
>  because some IOMMU HW can now accelerate TLB flush commands (among other 
> things). For instance, see the NVIDIA vIOMMU.

Hi Julien, I am not Teddy, but I have been considering the same
question, and here are the conclusions I reached.  

A virtual IOMMU of the same type as the underlying IOMMU provides better
operating system compatibility, particularly for running non-Linux OSes
such as Windows.  

On the other hand, a PV IOMMU should be faster to develop because there
is no need to emulate a hardware interface. Additionally, a single PV
IOMMU implementation could support multiple underlying hardware IOMMUs.
Specifically, it could be used for both Intel and AMD platforms.



> 
>       /**
>         * IOMMU_alloc_nested
>         * Create a nested IOMMU context (needs IOMMUCAP_nested).
>         *
>         * This context uses a platform-specific page table from domain address
>       space
>         * specified in pgtable_gfn and use it for nested translations.
>         *
>         * Explicit flushes needs to be submited with IOMMU_flush_nested on
>         * modification of the nested pagetable to ensure coherency between
>       IOTLB and
>         * nested page table.
>         *
>         * This context can be destroyed using IOMMU_free_context.
>         * This context cannot be modified using map_pages, unmap_pages.
>         */
>       struct pv_iommu_alloc_nested {
>            /* OUT: allocated IOMMU context number */
>            uint16_t ctx_no;
> 
>            /* IN: guest frame number of the nested page table */
>            uint64_aligned_t pgtable_gfn;
> 
>            /* IN: nested mode flags */
>            uint64_aligned_t nested_flags;
>       };
>       typedef struct pv_iommu_alloc_nested pv_iommu_alloc_nested_t;
>       DEFINE_XEN_GUEST_HANDLE(pv_iommu_alloc_nested_t);
> 
>       /**
>         * IOMMU_flush_nested (needs IOMMUCAP_nested)
>         * Flush the IOTLB for nested translation.
>         */
>       struct pv_iommu_flush_nested {
>            /* TODO */
>       };
>       typedef struct pv_iommu_flush_nested pv_iommu_flush_nested_t;
>       DEFINE_XEN_GUEST_HANDLE(pv_iommu_flush_nested_t);
> 
> 
>       >
>       >
>       >
>       >> [1] Originally
>       >> https://lists.xen.org/archives/html/xen-devel/2024-06/msg01145.html 
> but
>       >> this patch got quite old and probably doesn't work anymore with this 
> new
>       >> Xen patch series.
>       >> I have a updated patch in my xen-pviommu branch
>       >> 
> https://gitlab.com/xen-project/people/tsnake41/linux/-/commit/125d67a09fa9f66a32f9175641cfccca22dbbdb6
>       >>
>       >> [2] You also need to set 
> "vfio_iommu_type1.allow_unsafe_interrupts=1" to
>       >> make VFIO work for now.
> 
>       Thanks
>       Teddy
> 
> 
> 
>       Teddy Astie | Vates XCP-ng Developer
> 
>       XCP-ng & Xen Orchestra - Vates solutions
> 
>       web: https://vates.tech
> 
> 
>