On Tue, Nov 05, 2024 at 04:29:04PM -0700, Alex Williamson wrote: > > @@ -1,7 +1,7 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > config VIRTIO_VFIO_PCI > > tristate "VFIO support for VIRTIO NET PCI devices" > > - depends on VIRTIO_PCI && VIRTIO_PCI_ADMIN_LEGACY > > + depends on VIRTIO_PCI > > select VFIO_PCI_CORE > > help > > This provides support for exposing VIRTIO NET VF devices which support > > @@ -11,5 +11,7 @@ config VIRTIO_VFIO_PCI > > As of that this driver emulates I/O BAR in software to let a VF be > > seen as a transitional device by its users and let it work with > > a legacy driver. > > + In addition, it provides migration support for VIRTIO NET VF devices > > + using the VFIO framework. > > The first half of this now describes something that may or may not be > enabled by this config option and the additional help text for > migration is vague enough relative to PF requirements to get user > reports that the driver doesn't work as intended. Yes, I think the help should be clearer > For the former, maybe we still want a separate config item that's > optionally enabled if VIRTIO_VFIO_PCI && VFIO_PCI_ADMIN_LEGACY. If we are going to add a bunch of #ifdefs/etc for ADMIN_LEGACY we may as well just use VIRTIO_PCI_ADMIN_LEGACY directly and not introduce another kconfig for it? Is there any reason to compile out the migration support for virtio? No other drivers were doing this? kconfig combinations are painful, it woudl be nice to not make too many.. Jason
