Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU interface

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Hello Marek,
Thanks for your testing.

Le 23/01/2025 à 13:45, Marek Marczykowski-Górecki a écrit :
> Thanks for the updated patches. I have run them through gitlab-
ci, and
> here are some observations:
> - I needed to disable CONFIG_AMD_IOMMU (it fails to build, as expected at 
> this point)
> - I needed to disable pvshim (it fails to build)

> - fails to build with clang: 
> https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373789/viewer#L3525>
>  - gcc-ibt build fails:
https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373785#L1314

Looks like another cf_check related issue that I missed.

> - fails to build for ARM (both 32 and 64) and PPC64

This is expected like for the AMD_IOMMU part.

> - QEMU smoke test panic with PV dom0, looks like it runs on AMD, so it
>    may be related to the disabled CONFIG_AMD_IOMMU, but I wouldn't expect
>    it to panic on _PV_ dom0 boot...

Looks like I broke something when there is no IOMMU detected (removed
some check that should be there).

This patch should fix it (tested with QEMU without IOMMU).

---
diff --git a/xen/drivers/passthrough/context.c
b/xen/drivers/passthrough/context.c
index 6e68f840f3..98c84b439b 100644
--- a/xen/drivers/passthrough/context.c
+++ b/xen/drivers/passthrough/context.c
@@ -347,6 +347,10 @@ int iommu_iotlb_flush_all(struct domain *d, u16
ctx_no, unsigned int flush_flags
      struct iommu_context *ctx;
      int rc;

+    if ( !is_iommu_enabled(d) || !hd->platform_ops->iotlb_flush ||
+         !flush_flags )
+        return 0;
+
      if ( !(ctx = iommu_get_context(d, ctx_no)) )
          return -ENOENT;

---

> - PVH dom0 fails to boot (on real hw) with a lot of VT-d faults: 
> https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373875

I guess 00:02.0 is the iGPU. The addresses point to reserved memory in
E820 (is it the framebuffer ?) which should be reconfigured by the guest.

Is the guest dying (maybe due to the PVH Dom0 issue) before being able
to setup anything, causing the GPU to not be properly set ?
I tested a plain Alpine 3.18 PVH Dom0 and the kernel crashes very early
(6.1.123-0-lts though).

Or there is something else going wrong like with PCI Passthrough.
> - PCI passthrough (with PV dom0) results in a lot of VT-d faults:
> Note this uses only this series, but plain Linux (appears to be 6.1.19).
> IIUC if one doesn't try to configure PV-IOMMU specifically (non-default
> contexts) it should still work.

Yes, and PV-IOMMU drivers will likely not fix the issues you are facing.

>
> BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> 4.20 already at this point in release cycle?
>

It's probably because I mostly tested on Xen 4.19 (for practical reasons
to make toolstack happy), but I will update it to staging.

> All results:
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1637849303
>

Thanks

Teddy



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech