[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN RFC PATCH v5 3/5] xen/public: Introduce PV-IOMMU hypercall interface
Hi Stefano,
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.
I agree with both points. However what matters is the performance. In the case of nested, my concern with the PV approach is you are never going to reach the same performance as native. I am not talking about setting up the page tables, but more the TLB flushes. Have we measure the overhead and whether that’s acceptable?
With an emulated solution and HW support, virtual TLB flush could come for free because they will be handled directly by the HW. AFAICT, with a PV approach you are never going to be able to take advantage of this.
Cheers,
>
> /**
> * 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
>
>
>
|
