[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 11/11] xen/arm: translate virtual PCI bus topology for guests




On 08.11.21 16:23, Roger Pau Monné wrote:
> On Mon, Nov 08, 2021 at 11:16:42AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 08.11.21 13:10, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> --- a/xen/arch/arm/vpci.c
>>>> +++ b/xen/arch/arm/vpci.c
>>>> @@ -41,6 +41,15 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t 
>>>> *info,
>>>>        /* data is needed to prevent a pointer cast on 32bit */
>>>>        unsigned long data;
>>>>    
>>>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>>>> +    /*
>>>> +     * For the passed through devices we need to map their virtual SBDF
>>>> +     * to the physical PCI device being passed through.
>>>> +     */
>>>> +    if ( !bridge && !vpci_translate_virtual_device(v->domain, &sbdf) )
>>>> +            return 1;
>>> Nit: Indentation.
>> Ouch, sure
>>>> @@ -59,6 +68,15 @@ static int vpci_mmio_write(struct vcpu *v, mmio_info_t 
>>>> *info,
>>>>        struct pci_host_bridge *bridge = p;
>>>>        pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>>>>    
>>>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>>>> +    /*
>>>> +     * For the passed through devices we need to map their virtual SBDF
>>>> +     * to the physical PCI device being passed through.
>>>> +     */
>>>> +    if ( !bridge && !vpci_translate_virtual_device(v->domain, &sbdf) )
>>>> +            return 1;
>>> Again.
>> Will fix
>>>> @@ -172,10 +175,37 @@ REGISTER_VPCI_INIT(vpci_add_virtual_device, 
>>>> VPCI_PRIORITY_MIDDLE);
>>>>    static void vpci_remove_virtual_device(struct domain *d,
>>>>                                           const struct pci_dev *pdev)
>>>>    {
>>>> +    ASSERT(pcidevs_locked());
>>>> +
>>>>        clear_bit(pdev->vpci->guest_sbdf.dev, &d->vpci_dev_assigned_map);
>>>>        pdev->vpci->guest_sbdf.sbdf = ~0;
>>>>    }
>>>>    
>>>> +/*
>>>> + * Find the physical device which is mapped to the virtual device
>>>> + * and translate virtual SBDF to the physical one.
>>>> + */
>>>> +bool vpci_translate_virtual_device(struct domain *d, pci_sbdf_t *sbdf)
>>> const struct domain *d ?
>> Will change
>>>> +{
>>>> +    const struct pci_dev *pdev;
>>>> +    bool found = false;
>>>> +
>>>> +    pcidevs_lock();
>>>> +    for_each_pdev( d, pdev )
>>>> +    {
>>>> +        if ( pdev->vpci->guest_sbdf.sbdf == sbdf->sbdf )
>>>> +        {
>>>> +            /* Replace virtual SBDF with the physical one. */
>>>> +            *sbdf = pdev->sbdf;
>>>> +            found = true;
>>>> +            break;
>>>> +        }
>>>> +    }
>>>> +    pcidevs_unlock();
>>> I think the description wants to at least mention that in principle
>>> this is too coarse grained a lock, providing justification for why
>>> it is deemed good enough nevertheless. (Personally, as expressed
>>> before, I don't think the lock should be used here, but as long as
>>> Roger agrees with you, you're fine.)
>> Yes, makes sense
> Seeing as we don't take the lock in vpci_{read,write} I'm not sure we
> need it here either then.
Yes, I was not feeling confident while adding locking
> Since on Arm you will add devices to the guest at runtime (ie: while
> there could already be PCI accesses), have you seen issues with not
> taking the lock here?
No, I didn't. Neither I am aware of Arm had problems
But this could just mean that we were lucky not to step on it
>
> I think the whole pcidevs locking needs to be clarified, as it's
> currently a mess.
Agree
>   If you want to take it here that's fine, but overall
> there are issues in other places that would make removing a device at
> runtime not reliable.
So, what's the decision? I would leave the locks where I put them,
so at least this part won't need fixes.
>
> Thanks, Roger.
>
Thank you,
Oleksandr

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.