> From: Zhu, Lingshan <lingshan....@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.
