On 21.08.25 12:08, Jan Beulich wrote: > On 20.08.2025 14:28, Mykyta Poturai wrote: >> From: Luca Fancellu <luca.fance...@arm.com> >> >> In dom0less mode, there is no dom0 that can call PCI physdev ops to >> register PCI devices to iommu, so it needs to be done by Xen. >> pci_add_device requires some default domain, we don't have hwdom, and >> the guests are not yet created during the PCI init phase, so use dom_io >> as a temporary sentinel before devices are assigned to their target >> domains. >> >> Rename setup_hwdom_pci_devices to setup_pci_devices and add dom0less >> handling to it. >> >> In pci_add_device there is a call to xsm that doesn't consider the >> requester of the function to be Xen itself, so add a check to skip >> the call if the owner domain is dom_io, since it means the call is >> coming directly from Xen. >> >> Signed-off-by: Luca Fancellu <luca.fance...@arm.com> >> Signed-off-by: Mykyta Poturai <mykyta_potu...@epam.com> >> --- >> (cherry picked from commit eff51e50021b75f5a50533f7de681b2ce044f5bd from >> the downstream branch poc/pci-passthrough from >> https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc.git >> >> v1->v2: >> * integrate add_discovered_pci_devices into existing routines >> * better explain the need for dom_io > > What I continue to miss is an explanation of why devices can't go to their > ultimate "destination" domain right away (once those have been created), > i.e. why the dom_io intermediary is necessary in the first place. > > Jan
I've done some testing and indeed everything seems to work if we call pci_add_device directly during domain construction instead of reassigning them. Do you think this would be a better approach? If so then I guess this series needs to be dropped, and I will prepare a new one with direct device assignment to DomUs. -- Mykyta
