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 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE


> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, September 12, 2023 9:40 AM
> >
> > > Why this series can not support nested?
> > I donât see all the aspects that I covered in series [1] ranging from flr, device
> context migration, virtio level reset, dirty page tracking, p2p support, etc.
> covered in some device, vq suspend resume piece.
> >
> > [1]
> > https://lists.oasis-open.org/archives/virtio-comment/202309/msg00061.h
> > tml
> 
> The series works for stateless devices. Before we introduce device states in the
> spec, we can't migrate stateful devices. So the device context doesn't make
> much sense right now.
The series works for stateful devices too. The device context covers it.

> 
> Dirty page tracking in virtio is not a must for live migration to work. It can be
> done via platform facilities or even software. And to make it more efficient, it
> needs to utilize transport facilities instead of a general one.
> 
It is also optional in the spec proposal.
Most platforms claimed are not able to do efficiently either, hence the vfio subsystem added the support for it.

> The FLR, P2P demonstrates the fragility of a simple passthrough method and
> how it conflicts with live migration and complicates the device implementation.
Huh, it shows the opposite.
It shows that both will seamlessly work.

> And it means you need to audit all PCI features and do workaround if there're
> any possible issues (or using a whitelist).
No need for any of this.

> This is tricky and we are migrating virtio not virtio-pci. If we don't use simple
> passthrough we don't need to care about this.
> 
Exactly, we are migrating virtio device for the PCI transport.
As usual, if you have to keep arguing about not doing passhthrough, we are surely past that point.
Virtio does not need to stay in the weird umbrella to always mediate etc.

Series [1] will be enhanced further to support virtio passthrough device for device context and more.
Even further we like to extend the support.

> Since the functionality proposed in this series focus on the minimal set of the
> functionality for migration, it is virtio specific and self contained so nothing
> special is required to work in the nest.

Maybe it is.

Again, I repeat and like to converge the admin commands between passthrough and non-passthrough cases.
If we can converge it is good.
If not both modes can expand.
It is not either or as use cases are different.


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