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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jul 03, 2018 at 04:48:19AM -0600, Jan Beulich wrote:
> >>> On 03.07.18 at 12:21, <roger.pau@xxxxxxxxxx> wrote:
> > 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:
> >> > +            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?
> 
> I haven't checked yet where we are here - generally such delays would
> better be implemented by pausing the caller and resuming it once the
> necessary time has passed. While in Dom0 context it might be acceptable
> to do what Wei and you suggest, that'll be yet one more thing to deal
> with once we want to re-use the code for DomU-s.

I don't think we ever want to allow DomU-s to manage the SR-IOV
capability, so this code is always going to be Dom0 only AFAICT. In
fact I think I'm going to add an assert to that effect in the SR-IOV
init handler.

Thanks, Roger.

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