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

[Parav Pandit <parav@nvidia.com>]

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Wednesday, September 20, 2023 11:36 AM
> 
> On 9/19/2023 2:49 AM, Michael S. Tsirkin wrote:
> > On Mon, Sep 18, 2023 at 06:41:55PM +0000, Parav Pandit wrote:
> >>> Please refer to the code for setting FEATURES_OK.
> >> It wont work when one needs to suspend the device.
> >> There is no point of doing such work over registers as fundamental
> framework is over the AQ.
> > Well not really. It's over admin commands. When these were built the
> > intent always was that it's possible to use admin commands through
> > another interface, other than admin queue. Is there a problem
> > implementing admin commands over a memory BAR? For example, I can see
> > an "admin command" capability pointing at a BAR where commands are
> > supplied, and using a new group type referring to device itself.
> I am not sure, if a bar cap would be implemented as a proxy for the admin vq
> based live migration. then the problems of admin vq LM that we have discussed
> still exist. the bar is only a proxy, doesn't fix anything. and even larger side
> channel attacking surface: vf-->pf-->vf

AQ LM using PF has no side channel attack as hypervisor and owner device is trusted entity as already discussed.