Re: [PATCH RFC 12/19] vfio-user: probe remote device's BARs

[Alex Williamson]

On Tue, 20 Jul 2021 01:39:21 +0000
John Johnson <john.g.johnson@oracle.com> wrote:

> > On Jul 19, 2021, at 3:59 PM, Alex Williamson <alex.williamson@redhat.com> 
> > wrote:
> > 
> > On Sun, 18 Jul 2021 23:27:51 -0700
> > Elena Ufimtseva <elena.ufimtseva@oracle.com> wrote:  
> >> @@ -3442,6 +3448,22 @@ static void vfio_user_pci_realize(PCIDevice *pdev, 
> >> Error **errp)
> >>     /* QEMU can also add or extend BARs */
> >>     memset(vdev->emulated_config_bits + PCI_BASE_ADDRESS_0, 0xff, 6 * 4);
> >> 
> >> +    /*
> >> +     * Local QEMU overrides aren't allowed
> >> +     * They must be done in the device process
> >> +     */
> >> +    if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION) {
> >> +        error_setg(errp, "Multi-function must be specified by device 
> >> process");
> >> +        goto error;
> >> +    }
> >> +    if (pdev->romfile) {
> >> +        error_setg(errp, "Romfile must be specified by device process");
> >> +        goto error;
> >> +    }  
> > 
> > For what reason?  PCI functions can operate completely independently,
> > there could be different servers for different functions, a QEMU user
> > may wish to apply a different option ROM image than provided by the
> > server.  This all creates unnecessary incompatibilities.  Thanks,
> >   
> 
>       The idea is to have all the device options specified on the remote
> server, and have the vfio client just be a pass-through device.  I thought
> having them specified in 2 places would cause more confusion.

IMO, the server has no business making such configuration restrictions.
It's the client's decision if it wants to create multi-function
topologies or override the option rom.  Same for whether it wants to
override or virtualize capabilities.  All of this should just work
as-is; it's actually additional code required and knowledge through the
management stack to prevent it.  Thanks,

Alex