OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]