On 22.08.2025 10:03, Mykyta Poturai wrote: > 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. > > 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?
I think so, yes, but first and foremost you'll need Arm maintainer buyoff on either approach (or yet another one). Jan > If so > then I guess this series needs to be dropped, and I will prepare a new > one with direct device assignment to DomUs.
