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

[Jason Wang <jasowang@redhat.com>]

On Tue, Oct 24, 2023 at 12:49âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Tuesday, October 24, 2023 10:16 AM
> >
> > On Mon, Oct 23, 2023 at 12:42âPM Parav Pandit <parav@nvidia.com> wrote:
> > >
> > >
> > >
> > > > From: Jason Wang <jasowang@redhat.com>
> > > > Sent: Monday, October 23, 2023 9:15 AM
> > > >
> > > > On Thu, Oct 19, 2023 at 1:32âPM Parav Pandit <parav@nvidia.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > > From: virtio-comment@lists.oasis-open.org
> > > > > > <virtio-comment@lists.oasis- open.org> On Behalf Of Jason Wang
> > > > > > Sent: Thursday, October 19, 2023 10:15 AM
> > > > > >
> > > > > > > > Again, if you don't want to talk about transport virtqueue,
> > > > > > > > that's fine. But let's leave the scalability issue aside as well.
> > > > > > > >
> > > > > > > Registers are related for functionality and scale.
> > > > > > >
> > > > > > > Lets first agree on use case before the design, that I asked above.
> > > > > > >
> > > > > > > I will wait to respond to any other emails until we agree on
> > > > > > > use case
> > > > > > requirements.
> > > > > >
> > > > > > There are more than just me who want you to define "passthrough"
> > > > > > first where you refuse to respond.
> > > > > >
> > > > > Totally disagree.
> > > > > In the previous email itself, I wrote what passthrough is.
> > > > > So let's try yet one more time.
> > > > > Either you can re-read last email or for better read below and see
> > > > > if it is
> > > > understood or not.
> > > > >
> > > > > > How could we make any agreement without an accurate the
> > > > > > definition of "passthrough" who is a key to understand each other?
> > > > >
> > > > > I replied few times in past emails but since those email threads
> > > > > are so long, it is
> > > > easy to miss out.
> > > > >
> > > > > Passthrough definition:
> > > > > a. virtio member device mapped to the guest vm
> > > >
> > > > I really think we need to be accurate here. For example, what does
> > > > "map" mean here?
> > > >
> > > Not trapped by hypervisor is better wording than mapped.
> > >
> > > > > b. only pci config space and msix of a member device is
> > > > > intercepted by
> > > > hypervisor.
> > > >
> > > > What's the criteria for choosing a cap/bar to be trapped or not? For
> > > > example, there're a lot of other things that need to be virtualized besides
> > MSI-X for sure.
> > > >
> > > For passthrough, which are those?
> >
> > I haven't gone through all the caps but this is what in my mind
> >
> > 1) vIOMMU related stuffs: ATS/PRI, assign PASID to a virtqueue in the future
> > 2) capability related to resources: like Resizable BAR etc
> For passthrough PASID assignment vq is not needed.

How do you know that? There are works ongoing to make vPASID work for
the guest like vSVA. Virtio doesn't differ from other devices.

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

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

Thanks

>