From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
mst@redhat.com, jasowang@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, parav@nvidia.com,
feliu@nvidia.com, kevin.tian@intel.com,
joao.m.martins@oracle.com, leonro@nvidia.com, maorg@nvidia.com
Subject: Re: [PATCH V1 vfio 7/7] vfio/virtio: Enable live migration once VIRTIO_PCI was configured
Date: Wed, 6 Nov 2024 09:59:09 -0400 [thread overview]
Message-ID: <20241106135909.GO458827@nvidia.com> (raw)
In-Reply-To: <20241105162904.34b2114d.alex.williamson@redhat.com>
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
next prev parent reply other threads:[~2024-11-06 13:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 10:21 [PATCH V1 vfio 0/7] Enhance the vfio-virtio driver to support live migration Yishai Hadas
2024-11-04 10:21 ` [PATCH V1 vfio 1/7] virtio_pci: Introduce device parts access commands Yishai Hadas
2024-11-04 10:21 ` [PATCH V1 vfio 2/7] virtio: Extend the admin command to include the result size Yishai Hadas
2024-11-04 10:21 ` [PATCH V1 vfio 3/7] virtio: Manage device and driver capabilities via the admin commands Yishai Hadas
2024-11-04 10:21 ` [PATCH V1 vfio 4/7] virtio-pci: Introduce APIs to execute device parts " Yishai Hadas
2024-11-04 10:21 ` [PATCH V1 vfio 5/7] vfio/virtio: Add support for the basic live migration functionality Yishai Hadas
2024-11-05 22:47 ` Alex Williamson
2024-11-06 10:21 ` Yishai Hadas
2024-11-06 21:33 ` Alex Williamson
2024-11-07 9:39 ` Yishai Hadas
2024-11-06 15:48 ` Jason Gunthorpe
2024-11-04 10:21 ` [PATCH V1 vfio 6/7] vfio/virtio: Add PRE_COPY support for live migration Yishai Hadas
2024-11-05 23:18 ` Alex Williamson
2024-11-06 11:16 ` Yishai Hadas
2024-11-06 21:40 ` Alex Williamson
2024-11-04 10:21 ` [PATCH V1 vfio 7/7] vfio/virtio: Enable live migration once VIRTIO_PCI was configured Yishai Hadas
2024-11-05 23:29 ` Alex Williamson
2024-11-06 13:59 ` Jason Gunthorpe [this message]
2024-11-06 22:27 ` Alex Williamson
2024-11-07 12:57 ` Yishai Hadas
2024-11-07 21:25 ` Alex Williamson
2024-11-11 8:22 ` Yishai Hadas
2024-11-11 10:32 ` Joao Martins
2024-11-11 14:17 ` Yishai Hadas
2024-11-11 15:30 ` Joao Martins
2024-11-11 21:27 ` Alex Williamson
2024-11-06 9:32 ` [PATCH V1 vfio 0/7] Enhance the vfio-virtio driver to support live migration Michael S. Tsirkin
2024-11-06 22:30 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241106135909.GO458827@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=feliu@nvidia.com \
--cc=jasowang@redhat.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leonro@nvidia.com \
--cc=maorg@nvidia.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).