On Tue, 20 Jul 2021 01:39:21 +0000
John Johnson <john.g.john...@oracle.com> wrote:
> > On Jul 19, 2021, at 3:59 PM, Alex Williamson <alex.william...@redhat.com>
> > wrote:
> >
> > On Sun, 18 Jul 2021 23:27:51 -0700
> > Elena Ufimtseva <elena.ufimts...@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
