Re: [PATCH v4 4/4] xen/arm: add support for R-Car Gen4 PCI host controller

[Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>]

On 24.04.25 22:22, Stewart Hildebrand wrote:
> On 4/23/25 07:08, Mykyta Poturai wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>
>> Add support for Renesas R-Car Gen4 PCI host controller, specifically
>> targeting the S4 and V4H SoCs. The implementation includes configuration
>> read/write operations for both root and child buses. For accessing the
>> child bus, iATU is used for address translation.
> 
> In a system with dom0, I assume dom0 programs the iATU, and would do so
> before issuing any PHYSDEVOP_pci_device_add hypercalls or PCI config
> space accesses. Is that a correct assumption? If so, what is the use
> case for iATU initialization in Xen? E.g. is it to guard against a
> misconfigured or broken dom0? Do different iATU settings need to be
> applied when running as a Xen guest vs not?

dom0 can program iATU, but for guests, the programming should be done by 
Xen.

> Further, is this driver sufficient to initialize the PCI controller
> without dom0 involvement (e.g. to enable dom0less PCI passthrough)?

In the current state no. We are planning to add support for it in the 
future together with Xen device enumeration but it would also require 
changes to the bootloaders to deal with the initial host controller 
setup (clocks, resets, pincontrol, etc).

> These would all be valid use cases IMO, but I would just like to
> understand the rationale.
> 
> 
> dw_pcie_child_{map_bus,config_read,config_write}, and thus
> dw_pcie_prog_outbound_atu{_unroll}, would potentially be called on every
> guest PCI access, where the d->pci_lock may be held. It doesn't seem
> appropriate to have a busy-wait such as this in that code path.
> 
> If the busy-wait is necessary, then perhaps iATU configuration should
> happen during init/probe (as your FIXME note below suggests), not as a
> consequence of guest PCI access.
> 
> Same comment applies below.
> 
> 
> Does iATU configuration really need to happen on every guest PCI access?

It is possible to implement smarter allocation of iATU windows, but it 
would require at least a full control over the PCI host. For now we are 
doing the same approach as in Linux, of using window 0 for dynamic 
config space access and the rest for static mappings(configured by 
dom0). But overall there will always be a need for some dynamic 
configuration because there can be more devices than free ATU windows.

In practice with all of the hardware we tested on the ATU always 
configured in one pass of the wait loop, and the config space accesses 
are not that frequent so it shouldn't have a big impact on performance.

>> +
>> +    /*
>> +     * FIXME: we cannot read iATU unroll enable now as the host bridge's
>> +     * HW is not yet initialized by Domain-0: leave it for later.
>> +     */
> 
> Is there a plan to address this?
> 

We will need to address this to enable PCI scan by Xen.


-- 
Mykyta