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


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

Thanks


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