Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state

[Jason Wang <jasowang@redhat.com>]

On Thu, Sep 21, 2023 at 12:01âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, September 21, 2023 8:48 AM
>
> > As replied in another thread, the issues for BAR are:
> >
> > 1) Not sure it can have an efficient interface, it would be something like
> > VIRTIO_PCI_CAP_PCI_CFG which is very slow compared to single register
> > accessing
> > 2) There's no owner/group/member for MMIO, most of the time, we only need
> > a single MMIO device. If we want the owner to manage itself, it seems
> > redundant as is implied in all the existing transports (without admin commands).
> > Even if we had, it might still suffer from bootstrap issues.
> > 3) For live migration, it means the admin commands needs to start from
> > duplicating every existing transport specific interface it can give us. One
> > example is that we may end up with two interfaces to access virtqueue
> > addresses etc. This results in extra complicity and it is actually a full transport
> > (driver can just use admin commands to drive the device).
> In [1] there is no duplication. The live migration driver never parses the device context either while reading or write.
> Hence no code and no complexity in driver and no duplicate work.
> Therefore, those admin commands are not to drive the guest device either.

I'm not sure how this is related to the duplication issue.

>
> > 4) Admin commands itself may not be capable of doing things like dirty page
> > logging, it requires the assistance from the transport
> >
> Admin command in [1] is capable of dirty page logging.

In your design, the logging is done via DMA not the virtqueue.

The only job for virtqueue is to initiate the DMA. But if DMA can be
initiated via virtqueue, it can be done in other ways.

>
> > 1) Parav's proposal does several couplings: couple basic build blocks (suspend,
> > dirty page tracking) with live migration, couple live migration with admin
> > commands.
> In which use case you find dirty page tracking useful without migration for which you like to see it detached from device migration flow?

Is it only the dirty page tracking? It's the combinations of

1) suspending
2) device states
3) dirty page tracking

Eeah of those will have use cases other than live migration: VM stop,
power management in VM, profiling and monitoring, failover etc.

> One can always use these commands if they wish to as_is.
>
> > 2) It's still not clear that Parav's proposal can work, a lot of corner cases needs
> > to be examined
> >
> Please let me know which part can be improved in [1].

I will do that but it may take time. It's near to the public holiday.

Thanks

>
> [1] https://lore.kernel.org/virtio-comment/20230909142911.524407-7-parav@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead
>
>
> > >
> > > > the bar is only a proxy, doesn't fix anything. and even larger side
> > > > channel attacking surface: vf-->pf-->vf
> > >
> > > In this model there's no pf. BAR belongs to vf itself and you submit
> > > commands for the VF through its BAR.
> > > Just separate from the pci config space.
> > >
> > > The whole attacking surface discussion is also puzzling.  We either
> > > are or are not discussing confidential computing/TDI.  I couldn't
> > > figure it out. This needs a separate thread I think.
> >
> > Anyhow, it's not bad to take it into consideration. But we can do it elsewhere for
> > sure.
> Thanks.
> Please have comments in [1].
>
> [1] https://lore.kernel.org/virtio-comment/20230909142911.524407-7-parav@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead
>