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

Re: [Xen-devel] [PATCH 10/10] vpci/sriov: add support for SR-IOV capability



On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> > +        /* Set the BARs addresses and size. */
> > +        for ( i = 0; i < PCI_SRIOV_NUM_BARS; i += rc )
> > +        {
> > +            unsigned int j, idx = pos + PCI_SRIOV_BAR + i * 4;
> > +            const pci_sbdf_t sbdf = {
> > +                .sbdf = PCI_SBDF3(pdev->seg, pdev->bus, pdev->devfn),
> > +            };
> > +            uint32_t bar = pci_conf_read32(pdev->seg, pdev->bus,
> > +                                           PCI_SLOT(pdev->devfn),
> > +                                           PCI_FUNC(pdev->devfn), idx);
> > +            uint64_t addr, size;
> > +
> > +            rc = pci_size_mem_bar(sbdf, idx, &addr, &size,
> > +                                  PCI_BAR_VF |
> > +                                  ((i == PCI_SRIOV_NUM_BARS - 1) ?
> > +                                   PCI_BAR_LAST : 0));
> 
> This only returns 1 or 2. The return type is unsigned int which means rc
> is never going to be <= 0.

Right... I will replace the if with an ASSERT(rc > 0 && rc <= 2);

> > +             */
> > +            sriov->num_vfs = pci_conf_read16(pdev->seg, pdev->bus,
> > +                                             PCI_SLOT(pdev->devfn),
> > +                                             PCI_FUNC(pdev->devfn),
> > +                                             pos + PCI_SRIOV_NUM_VF);
> > +
> > +            /*
> > +             * NB: VFE needs to be enabled before calling pci_add_device 
> > so Xen
> > +             * can access the config space of VFs.
> > +             */
> > +            pci_conf_write16(pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> > +                             PCI_FUNC(pdev->devfn), reg,
> > +                             control | PCI_SRIOV_CTRL_VFE);
> > +
> > +            /*
> > +             * The spec states that the software must wait at least 100ms
> > +             * before attempting to access VF registers when enabling 
> > virtual
> > +             * functions on the PF.
> > +             */
> > +            mdelay(100);
> 
> IMHO delaying 100ms like this in an active system is far too long. It
> would be better to put this into a loop and process softirqs in between
> delays.

Ack, do you think 10ms delays would be OK?

> > +        }
> > +
> > +        for ( i = 0; i < sriov->num_vfs; i++ )
> > +        {
> > +            const pci_sbdf_t bdf = {
> > +                .bdf = PCI_BDF2(pdev->bus, pdev->devfn) + offset + stride 
> > * i,
> > +            };
> > +
> > +            if ( new_enabled )
> > +            {
> > +                const struct pci_dev_info info = {
> > +                    .is_virtfn = true,
> > +                    .physfn.bus = pdev->bus,
> > +                    .physfn.devfn = pdev->devfn,
> > +                };
> > +
> > +                rc = pci_add_device(pdev->seg, bdf.bus, bdf.extfunc, &info,
> > +                                    pdev->node);
> > +            }
> > +            else
> > +                rc = pci_remove_device(pdev->seg, bdf.bus, bdf.extfunc);
> > +            if ( rc )
> > +                gprintk(XENLOG_ERR, "failed to %s VF %04x:%02x:%02x.%u: 
> > %d\n",
> > +                        new_enabled ? "add" : "remove", pdev->seg, bdf.bus,
> > +                        bdf.dev, bdf.func, rc);
> > +
> > +            pcidevs_lock();
> > +            sriov->vf[i] = pci_get_pdev(pdev->seg, bdf.bus, bdf.extfunc);
> > +            pcidevs_unlock();
> 
> So the array is updated regardless of rc?

Yes, in the addition case the code is capable of dealing with a NULL
entry in the array (or that was the intention). In the case of a
failed removal an entry in the array won't be NULL, but I don't think
that's an issue.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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