Re: [PATCH v5 08/10] xen/arm: Setup MMIO range trap handlers for hardware domain

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

Hi, Roger!

On 13.10.21 13:11, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>
>> In order for vPCI to work it needs to maintain guest and hardware
>> domain's views of the configuration space. For example, BARs and
>> COMMAND registers require emulation for guests and the guest view
>> of the registers needs to be in sync with the real contents of the
>> relevant registers. For that ECAM address space needs to also be
>> trapped for the hardware domain, so we need to implement PCI host
>> bridge specific callbacks to properly setup MMIO handlers for those
>> ranges depending on particular host bridge implementation.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>> Reviewed-by: Rahul Singh <rahul.singh@xxxxxxx>
>> Tested-by: Rahul Singh <rahul.singh@xxxxxxx>
>> ---
>> Since v3:
>> - fixed comment formatting
>> Since v2:
>> - removed unneeded assignment (count = 0)
>> - removed unneeded header inclusion
>> - update commit message
>> Since v1:
>>   - Dynamically calculate the number of MMIO handlers required for vPCI
>>     and update the total number accordingly
>>   - s/clb/cb
>>   - Do not introduce a new callback for MMIO handler setup
>> ---
>>   xen/arch/arm/domain.c              |  2 ++
>>   xen/arch/arm/pci/pci-host-common.c | 28 ++++++++++++++++++++++++
>>   xen/arch/arm/vpci.c                | 34 ++++++++++++++++++++++++++++++
>>   xen/arch/arm/vpci.h                |  6 ++++++
>>   xen/include/asm-arm/pci.h          |  5 +++++
>>   5 files changed, 75 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 79012bf77757..fa6fcc5e467c 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -733,6 +733,8 @@ int arch_domain_create(struct domain *d,
>>       if ( (rc = domain_vgic_register(d, &count)) != 0 )
>>           goto fail;
>>   
>> +    count += domain_vpci_get_num_mmio_handlers(d);
>> +
>>       if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
> IMO it might be better to convert the fixed array into a linked list,
> I guess this made sense when Arm had a very limited number of mmio
> trap handlers, but having to do all this accounting seems quite
> tedious every time you want to add new handlers.
Yes, I think we need to do so, but this improvement was not meant
to be in this patch.
>
>>           goto fail;
>>   
>> diff --git a/xen/arch/arm/pci/pci-host-common.c 
>> b/xen/arch/arm/pci/pci-host-common.c
>> index 592c01aae5bb..1eb4daa87365 100644
>> --- a/xen/arch/arm/pci/pci-host-common.c
>> +++ b/xen/arch/arm/pci/pci-host-common.c
>> @@ -292,6 +292,34 @@ struct dt_device_node *pci_find_host_bridge_node(struct 
>> device *dev)
>>       }
>>       return bridge->dt_node;
>>   }
>> +
>> +int pci_host_iterate_bridges(struct domain *d,
>> +                             int (*cb)(struct domain *d,
>> +                                       struct pci_host_bridge *bridge))
>> +{
>> +    struct pci_host_bridge *bridge;
>> +    int err;
>> +
>> +    list_for_each_entry( bridge, &pci_host_bridges, node )
>> +    {
>> +        err = cb(d, bridge);
>> +        if ( err )
>> +            return err;
>> +    }
>> +    return 0;
>> +}
>> +
>> +int pci_host_get_num_bridges(void)
>> +{
>> +    struct pci_host_bridge *bridge;
>> +    int count = 0;
> unsigned int for both the local variable and the return type.
Ok
>
>> +
>> +    list_for_each_entry( bridge, &pci_host_bridges, node )
>> +        count++;
>> +
>> +    return count;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
>> index 76c12b92814f..6e179cd3010b 100644
>> --- a/xen/arch/arm/vpci.c
>> +++ b/xen/arch/arm/vpci.c
>> @@ -80,17 +80,51 @@ static const struct mmio_handler_ops vpci_mmio_handler = 
>> {
>>       .write = vpci_mmio_write,
>>   };
>>   
>> +static int vpci_setup_mmio_handler(struct domain *d,
>> +                                   struct pci_host_bridge *bridge)
>> +{
>> +    struct pci_config_window *cfg = bridge->cfg;
>> +
>> +    register_mmio_handler(d, &vpci_mmio_handler,
>> +                          cfg->phys_addr, cfg->size, NULL);
> I'm confused here, don't you need to use a slightly different handler
> for dom0 so that you can differentiate between the segments of the
> host bridges?
>
> AFAICT the translation done by vpci_mmio_handler using MMCFG_BDF
> always assume segment 0.
You are absolutely right here: I can set up hwdom specific
handlers, so I can properly translate the segment.
On the other hand, when virtual bus topology added, the SBDF
translation from virtual to physical SBDF resides in the Arm's
vpci_mmio_{read|write}, like the below:
     if ( priv->is_virt_ecam &&
          !vpci_translate_virtual_device(v->domain, &sbdf) )
             return 1;
(BTW Jan asked in some other comment why it is Arm specific:
I tend to keep it Arm specific until the point when x86 wants that
as well. Until that point the code, if moved to common, will be
unneeded and as Jan calls that "dead")
So, I think that I can extend vpci_mmio_{read|write} to account
on the hwdom like (virtual bus code is the future code):

static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
                           register_t *r, void *p)
{
...
     struct vpci_mmio_priv *priv = (struct vpci_mmio_priv *)p;

     if ( priv->is_virt_ecam )
         sbdf.sbdf = MMCFG_BDF(info->gpa); /* For virtual bus topology the 
segment is always 0. */
     else
     {
         sbdf.sbdf = MMCFG_BDF(info->gpa);
         sbdf.seg = priv->segment;
     }
     reg = REGISTER_OFFSET(info->gpa);

...
     /*
      * For the passed through devices we need to map their virtual SBDF
      * to the physical PCI device being passed through.
      */
     if ( priv->is_virt_ecam &&
          !vpci_translate_virtual_device(v->domain, &sbdf) )
             return 1;

Will it work for you?
>
>> +    return 0;
>> +}
>> +
>>   int domain_vpci_init(struct domain *d)
>>   {
>>       if ( !has_vpci(d) )
>>           return 0;
>>   
>> +    if ( is_hardware_domain(d) )
>> +        return pci_host_iterate_bridges(d, vpci_setup_mmio_handler);
>> +
>> +    /* Guest domains use what is programmed in their device tree. */
>>       register_mmio_handler(d, &vpci_mmio_handler,
>>                             GUEST_VPCI_ECAM_BASE, GUEST_VPCI_ECAM_SIZE, 
>> NULL);
>>   
>>       return 0;
>>   }
>>   
>> +int domain_vpci_get_num_mmio_handlers(struct domain *d)
>> +{
>> +    int count;
> unsigned for both types.
Ok
>
>> +
>> +    if ( is_hardware_domain(d) )
>> +        /* For each PCI host bridge's configuration space. */
>> +        count = pci_host_get_num_bridges();
> There's no need to trap MSI-X Table/PBA accesses for dom0 I assume?
No need
>
>> +    else
>> +        /*
>> +         * VPCI_MSIX_MEM_NUM handlers for MSI-X tables per each PCI device
>> +         * being passed through. Maximum number of supported devices
>> +         * is 32 as virtual bus topology emulates the devices as embedded
>> +         * endpoints.
>> +         * +1 for a single emulated host bridge's configuration space.
>> +         */
>> +        count = VPCI_MSIX_MEM_NUM * 32 + 1;
> There's a single MSI-X mmio handler that deals with both PBA and MSIX
> tables, so I don't see the need to * VPCI_MSIX_MEM_NUM.
Yes, thank you, it is indeed, so the number can be reduced
>
> Thanks, Roger.
Thank you,
Oleksandr