[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [PATCH v1 3/8] device-context: Define the device context fields for device migration
On Fri, Oct 20, 2023 at 5:41âPM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, Oct 20, 2023 at 05:31:01PM +0800, Zhu, Lingshan wrote: > > > > > > On 10/19/2023 6:33 PM, Parav Pandit wrote: > > > > From: Zhu, Lingshan <lingshan.zhu@intel.com> > > > > Sent: Thursday, October 19, 2023 2:48 PM > > > > > > > > On 10/19/2023 5:14 PM, Michael S. Tsirkin wrote: > > > > > On Thu, Oct 19, 2023 at 09:13:16AM +0000, Parav Pandit wrote: > > > > > > > Oh, really? Quite interesting, do you want to move all config space > > > > > > > fields in VF to admin vq? Have a plan? > > > > > > Not in my plan for spec 1.4 time frame. > > > > > > I do not want to divert the discussion, would like to focus on device > > > > migration phases. > > > > > > Lets please discuss in some other dedicated thread. > > > > > Possibly, if there's a way to send admin commands to vf itself then > > > > > Lingshan will be happy? > > > > still need to prove why admin commands are better than registers. > > > Virtio spec development is not proof based approach. Please stop asking for it. > > > > > > I tried my best to have technical answer in [1]. > > > I explained that registers simply do not work for passthrough mode > > > (if this is what you are asking when you are asking prove its better). > > > They can work for non_passthrough mediated mode. > > > > > > A member device may do admin commands using registers. Michael and I are discussing presently in the same thread. > > > > > > Since there are multiple things to be done for device migration, dedicated register set for each functionality do not scale well, hard to maintain and extend. > > > A register holding a command content make sense. > > > > > > Now, with that, if this can be useful only for non_passthrough, I made humble request to transport them using AQ, this way, you get all benefits of AQ. > > > And trying to understand, why AQ cannot possible or inferior? > > > > > > If you have commands like suspend/resume device, register or queue transport simply donât work, because it's wrong to bifurcate the device with such weird API. > > > If you want to biferacate for mediation software, it probably makes sense to operate at each VQ level, config space level. Such are very different commands than passthrough. > > > I think vdpa has demonstrated that very well on how to do specific work for specific device type. So some of those work can be done using AQ. > > > > > > [1] 870ace02-f99c-4582-932f-bd103362dae9@intel.com/T/#m37743aa924536d0256d6b3b8e83a11c750f28794">https://lore.kernel.org/virtio-comment/870ace02-f99c-4582-932f-bd103362dae9@intel.com/T/#m37743aa924536d0256d6b3b8e83a11c750f28794 > > We have been through your statement for many times. > > This is not about how many times you repeated, if you think this is true, > > you need to prove that with solid evidence. > > > > > > For pass-through, I still recommend you to take a reference of current > > virito-pci implementation, it works for pass-through, right? > > Current migration implementation in e.g. QEMU? It does but it > traps data path accesses. That, I think we can agree, > should not be the only option to migrate. > > > For scale, I already told you for many times that they are per-device > > facilities. How can a per-device facility not scale? > > vDPA works fine on config space. > > > > So, if you still insist admin vq is better than config space like in other > > thread you have concluded, you may imply that config space interfaces should > > be re-factored to admin vq. > > There are good arguments that yes, virtio needs a transport for config space > that is DMA based as opposed to memory mapped based. This is one of the > things all vendors seem to prefer in IDPF so virtio should have the option. Then it is the transport vq or transport over adminq proposal? Thanks > > > -- > MST > > > This publicly archived list offers a means to provide input to the > OASIS Virtual I/O Device (VIRTIO) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe: virtio-comment-subscribe@lists.oasis-open.org > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org > List help: virtio-comment-help@lists.oasis-open.org > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf > List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists > Committee: https://www.oasis-open.org/committees/virtio/ > Join OASIS: https://www.oasis-open.org/join/ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]