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

[Jason Andryuk <jason.andryuk@xxxxxxx>]

Hi Teddy,

Thanks for working on this.  I'm curious about your plans for this:

On 2025-01-21 11:13, Teddy Astie wrote:
> +/**
> + * 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);
Is this command intended to be used for GVA -> GPA translation?  Would 
you need some way to associate with another iommu context for GPA -> HPA 
translation?
Maybe more broadly, what are your goals for enabling PV-IOMMU?  The 
examples on your blog post cover a domain restrict device access to 
specific portions of the the GPA space.  Are you also interested in GVA 
-> GPA?  Does VFIO required GVA -> GPA?
And, sorry to bike shed, but ctx_no reads like "Context No" to me.  I 
think ctxid/ctx_id might be clearer.  Others probably have their own 
opinions :)
Thanks,
Jason