On Fri, 22 Aug 2025, Jan Beulich wrote: > 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).
I am OK with that in principle
