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

Reply via email to