Re: [PATCH v9 7/8] xen/arm: enable dom0 to use PCI devices with pci-passthrough=no

[Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>]

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.

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. 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.

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.

-- 
Mykyta