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

[Jason Wang <jasowang@redhat.com>]

On Wed, Sep 20, 2023 at 6:36âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Sep 20, 2023 at 02:06:13PM +0800, Zhu, Lingshan wrote:
> >
> >
> > 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.
>
> Not a proxy for a vq in that there's no vq then.

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).
4) Admin commands itself may not be capable of doing things like dirty
page logging, it requires the assistance from the transport

>
> > then the problems of admin vq LM that we have
> > discussed
> > still exist.
>
> I freely admit the finer points of this extended flamewar have been lost
> on me, and I wager I'm not the only one. I thought you wanted to migrate
> the device just by accessing the device itself (e.g. the VF) without
> accessing other devices (e.g. the PF), while Parav wants it in a
> separate device so the whole of the device itself can passed through to
> guest.

If accessing the device itself, anything prevents us from passing it
through to the guest? It is how all the existing devices are built.

> Isn't this, fundamentally, the issue?

For me it's not. The fundamental issues are:

1) Parav's proposal does several couplings: couple basic build blocks
(suspend, dirty page tracking) with live migration, couple live
migration with admin commands. This proposal doesn't do such coupling,
and admin commands can be built on top.
2) It's still not clear that Parav's proposal can work, a lot of
corner cases needs to be examined

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





>
> --
> MST
>