Re: [virtio-comment] [PATCH v1 1/8] admin: Add theory of operation for device migration

[Jason Wang <jasowang@redhat.com>]

On Wed, Oct 25, 2023 at 3:03âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Wednesday, October 25, 2023 6:59 AM
> > > For passthrough PASID assignment vq is not needed.
> >
> > How do you know that?
> Because for passthrough, the hypervisor is not involved in dealing with VQ at all.

Ok, so if I understand correctly, you are saying your design can't
work for the case of PASID assignment.

>
> > There are works ongoing to make vPASID work for the
> > guest like vSVA. Virtio doesn't differ from other devices.
> Passthrough do not run like SVA.

Great, you find another limitation of "passthrough" by yourself.

> Each passthrough device has PASID from its own space fully managed by the guest.
> Some cpu required vPASID and SIOV is not going this way anmore.

Then how to migrate? Invent a full set of something else through
another giant series like this to migrate to the SIOV thing? That's a
mess for sure.

>
> >
> > > If at all it is done, it will be done from the guest by the driver using virtio
> > interface.
> >
> > Then you need to trap. Such things couldn't be passed through to guests directly.
> >
> Only PASID capability is trapped. PASID allocation and usage is directly from guest.

How can you achieve this? Assigning a PAISD to a device is completely
device(virtio) specific. How can you use a general layer without the
knowledge of virtio to trap that?

> Regardless it is not relevant to passthrough mode as PASID is yet another resource.
> And for some cpu if it is trapped, it is generic layer, that does not require virtio involvement.
> So virtio interface asking to trap something because generic facility has done in not the approach.

This misses the point of PASID. How to use PASID is totally device specific.

>
> > > Capabilities of #2 is generic across all pci devices, so it will be handled by the
> > HV.
> > > ATS/PRI cap is also generic manner handled by the HV and PCI device.
> >
> > No, ATS/PRI requires the cooperation from the vIOMMU. You can simply do
> > ATS/PRI passthrough but with an emulated vIOMMU.
> And that is not the reason for virtio device to build trap+emulation for passthrough member devices.

vIOMMU is emulated by hypervisor with a PRI queue, how can you pass
through a hardware PRI request to a guest directly without trapping it
then? What's more, PCIE allows the PRI to be done in a vendor (virtio)
specific way, so you want to break this rule? Or you want to blacklist
ATS/PRI for virtio?

Thanks