> From: Jason Wang <>
> Sent: Monday, October 23, 2023 9:15 AM
>
> On Thu, Oct 19, 2023 at 1:32âPM Parav Pandit <> wrote:
> >
> >
> >
> > > From:
> > > <- 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?
> > c. virtio config space, virtio cvqs, data vqs of a member device is directly
> accessed by the guest vm without intercepted by the hypervisor.
> >
> > (Why b?, no grand reason, it is how the hypervisors are working where to
> integrate the virtio member device to).
>
> What you state here is more about the method to support a use case not the
> use case itself. My understanding is "live migration" is a valid use case for sure.
> And "passthough" is probably one way for achieving live migration but this is
> what you need to define and justify in this series.
>
I largely captured that in v2 in device context and in theory of operation.
I will keep it short as written in v2. If something is unclear (without writing the book), I am happy to extend it.
