RE: [virtio-comment] [PATCH 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, September 12, 2023 9:14 AM
> 
> On Mon, Sep 11, 2023 at 7:50âPM Parav Pandit <parav@nvidia.com> wrote:
> >
> > > From: Zhu, Lingshan <lingshan.zhu@intel.com>
> > > Sent: Monday, September 11, 2023 3:03 PM
> >
> > > By the way, do you see anything we need to improve in this series?
> >
> > Admin commands for passthrough devices of [1] is comprehensive proposal
> covering all the aspects.
> 
> What do you mean by "all the aspects"?
They are covered in the proposal cover letter.
1. state migration, p2p, dirty page tracking, lower downtime, flr, device reset, no extra mediation requirement.

> 
> Of course it can't handle nesting well, passthrough doesn't work when your
> hardware has N levels abstractions but nesting is M levels. Trap and emulation
> is a must.
One can delicate the work to other VF for purpose of nesting.

One can build infinite level of nesting to not do passthrough, at the end user applications remains slow.
So for such N and M being > 1, one can use software base emulation anyway.

> 
> And exposing the whole device to the guest drivers will have security
> implications, your proposal has demonstrated that you need a workaround for
There is no security implications in passthrough.

> FLR at least.
It is actually the opposite.
FLR is supported with the proposal without any workarounds and mediation.

> 
> For non standard device we don't have choices other than passthrough, but for
> standard devices we have other choices.

Passthrough is basic requirement that we will be fulfilling.
If one wants to do special nesting, may be, there.
If both commands can converge its good, if not, they are orthogonal requirements.