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

[Parav Pandit <parav@nvidia.com>]

> 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.

> 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.
 
> 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?
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].

[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