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