Re: [virtio-comment] Re: [PATCH v1 3/8] device-context: Define the device context fields for device migration

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 10/19/2023 4:37 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 19, 2023 at 04:18:42PM +0800, Zhu, Lingshan wrote:
> > On 10/18/2023 6:47 PM, Michael S. Tsirkin wrote:
> > > On Wed, Oct 18, 2023 at 10:22:57AM +0000, Parav Pandit wrote:
> > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > Sent: Wednesday, October 18, 2023 3:26 PM
> > > > > For completeness, and to shorten the thread, can you please list known
> > > > > issues/use cases that are addressed by the status bit interface and how you plan
> > > > > for them to be addressed?
> > > > I will avoid listing known issues for a moment for status bit in this email.
> > > >
> > > > Status bit interface helps in following good ways.
> > > > 1. suspend/resume the device fully by the guest by negotiating the new feature.
> > > > This can be useful in the guest-controlled PM flows of suspend/resume.
> > > > I still think for this, only feature bit is necessary, and device_status modification is not needed.
> > > > D0->D3 and D3->D0 transition of the pci can suspend and resume the device which can preserve the last device_status value before entering D3.
> > > > (Like preserving all rest of the fields of common and other device config).
> > > > This is orthogonal and needed regardless of device migration.
> > > >
> > > > 2. If one does not want to passthrough a member device, but build a mediation-based device on top of existing virtio device,
> > > > It can be useful with mediating software.
> > > > Here the mediating software has ample duplicated knowledge of what the member device already has.
> > > > This can fulfil the nested requirement differently provided a platform support it.
> > > > (PASID limitation will be practical blocker here).
> > > >
> > > > How to I plan to address above two?
> > > > a. #1 to be addressed by having the _F_PM bit, when the bit is negotiated PCI PM drives the state.
> > > > This will work orthogonal to VMM side migration and will co-exist with VMM based device migration.
> > > OK that sounds kind of reasonable. Lingshan, Jason are you interested in
> > > suspend/resume? Want to start a thread on best way to support that?
> > suspend/resume a device through PM? why? is the status bit in my series
> > better?
> I don't know. If we can please stop discussing suspend in live migration
> thread and have one with focus on suspend then maybe that's exactly what
> is needed.  Is there even a problem we need to solve? Do we need to stop
> vqs or is reset as done currently good enough?
I have been asked the question above, so I raise my concern, nothing more.
> Let's focus on that and then hopefully these flamewars can finally stop?
OK
> > > > b. nested use case:
> > > > L0 VMM maps a VF to L1 guest as PF with emulated SR-IOV capability.
> > > > L1 guest to enable SR-IOV and mapping the VF to L2 guest.
> > > > Consulting industry ecosystem to support nested outside of virtio.
> > > Can't say I like this much, *a lot* of things to implement,
> > > and burning up a VF for control path is not nice.
> > > As an alternative, I suggest a new admin command pci capability
> > > with basically a PA and a valid bit. Easy to emulate and add to
> > > a VF. And maybe some way to suggest a safe place for it that
> > > won't conflict with anything? Still trying to figure out if
> > > we should add PASID in there, or what. Maybe optionally?
> > > If actual hardware does it we'd be burning up 20 bits,
> > > but for a software implementation it's free.
>
> 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/