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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.01.2025 21:17, Jason Andryuk wrote:
> 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 :)

Or, if it absolutely is to derive from "number", ctx_nr. That said, I
agree "id" is a better term to use here.

Jan