Re: [virtio-comment] Re: [PATCH V2 4/6] virtio-pci: implement VIRTIO_F_QUEUE_STATE

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 22, 2023 at 12:15:44PM +0800, Jason Wang wrote:
> On Wed, Nov 22, 2023 at 12:26âAM Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Tuesday, November 21, 2023 10:01 AM
> > >
> > > On Fri, Nov 17, 2023 at 6:06âPM Parav Pandit <parav@nvidia.com> wrote:
> > > >
> > > >
> 
> [...]
> 
> > > > Sorry, no virtio specification does not support device migration today.
> > > > Nothing is broken by adding new features.
> > > >
> > > > Above [1] has the right proposal that Jason's paper pointed out. Please use
> > > it.
> > >
> > > I was involved in the design in [1]. And I don't see a connection to the
> > > dicussion here
> > >
> > > 1) It is based on vDPA in L0
> > > 2) It doesn't address the nesting issue, it requires a proper design in the virtio
> > > spec to support migration in the nesting layer.
> >
> > Nothing prevents [1] to be done without vdpa.
> 
> Well, Qemu has SR-IOV emulation for IGB. What's the point of the above
> reply? If a hypervisor wishes, it can be done with any device on L0.
> 
> We discuss the possibility of migrating nested VMs, not the
> possibility of emulating SR-IOV, no?
> 
> Thanks

It depends really. If the way to support nesting is to emulate sr-iov
then the question becomes how hard it is to emulate sriov to the point
where nesting works.

The fact that current hypervisors pretend that a VF is a PF when
passing things on to guest and things still seem to work is
nice but it's not a hugely important design point IMHO.

-- 
MST