|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v9 7/8] xen/arm: enable dom0 to use PCI devices with pci-passthrough=no
On 28.04.25 21:15, Julien Grall wrote: > Hi Mykyta, > > On 28/04/2025 15:28, Mykyta Poturai wrote: >> On 28.04.25 15:55, Julien Grall wrote: >>> Hi, >>> >>> On 28/04/2025 13:31, Mykyta Poturai wrote: >>>> On 28.04.25 11:54, Julien Grall wrote: >>>>> Hi Mykyta, >>>>> >>>>> On 14/03/2025 13:34, Mykyta Poturai wrote: >>>>>> From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx> >>>>>> >>>>>> Enable the use of IOMMU + PCI in dom0 without having to specify >>>>>> "pci-passthrough=yes". We rely on dom0 to initialize the PCI >>>>>> controller >>>>>> and perform a PHYSDEVOP_pci_device_add call to add each device to >>>>>> SMMU. >>>>> >>>>> It would be good to explain why Xen cannot initialize the PCI >>>>> controller. Asking, because the reason is the PCI controller is too >>>>> complex, then you will likely need the same approach for PCI >>>>> passthrough... >>>> >>>> I think the main reason for this is complexity and the possibility of >>>> additional dependencies: there could be external clocks or reset pins >>>> that the PCI host depends on for working correctly. I will add this to >>>> the commit message. Regarding PCI passthrough, it is already using the >>>> same approach (at least on Arm). There are patches for enabling Xen on >>>> Arm to perform bus enumeration by itself by Luca Fancellu, but I >>>> haven't >>>> yet got to test them in a meaningful way. >>> >>> Can you provide a link to the series? I would like to make sure we have >>> a coherent approach. In particular, it is not clear to me how Dom0 and >>> Xen will be able to coordinate the access to the PCI controller. Are we >>> going to have a mediator? >>> >> >> Here is a link to my WIP branch >> https://github.com/Deedone/xen/tree/pci_passthrough_wip >> Although it is slightly outdated due to recent review activity, I will >> updated it soon with all of the recent changes. >> >> Luca's commits begin from c68a5cbb1a7d17907551159c99ab5c87ce0dedf9 >> >> I wasn't able to find them sent to any mailing lists, but I plan to also >> send them after the base case with Dom0 enumeration stabilizes. > > I don't think you can stabilize one without the other. I am worry the > interface may not work properly for PCI passthrough. So until then, I > would say this should be marked as unsupported (maybe protected by > CONFIG_UNSUPPORTED). It is currently not possible to enable HAS_PCI on Arm at all. I will add the UNSUPPORTED guard along with the future changes to Kconfig that will make enabling HAS_PCI on Arm possible. >> >> There is no mediator, Dom0 configures the host controller, enumerates >> child devices, and then gives complete access to some of them to Xen. >> Xen only does "logical" operations with child devices and does not >> change any of the host controller base settings. > > I am not sure I fully understanding this. Both dom0 will need to access > the configuration space. So you would need to ensure there is only one > accessing the configuration space at a give time. > If a controller doesn't require specific configuration for mapping child bus then Xen should access only child's config space and if Dom0 ignores this device there will be no conflicts. For more complex controllers like the ones on R-Car boards it is possible to implement safer ways of mapping config space via Xen, example patch here[1] as temporary solution. >> To ensure that Dom0 >> will not mess with the child devices, tools bind them to the stub >> driver. Theoretically, Dom0 can bind to those devices again and break >> something, but it can also do a lot of other breaking stuff so I don't >> think there is a good reason to invent some forms of protection from it. > > We should not trust dom0 to do the right thing. But reading ... > >> >> After some time with pci-scan changes merged it should become possible >> to make Xen do the enumeration, and only give Dom0 the virtual PCI bus, >> which would prevent it from accessing non-owned devices. > > ... this it sounds like this would be temporary. Do you have patches > already on the mailing list? > > Cheers, > Not yet, I am planning to start working on them after dealing with MSI support on Arm. [1]: https://github.com/xen-troops/meta-xt-prod-devel-rcar-gen4/blob/master/layers/meta-xt-domd-gen4/recipes-kernel/linux/linux-renesas/0005-HACK-pcie-renesas-emulate-reading-from-ECAM-under-Xe.patch -- Mykyta
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |