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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 19, 2023 at 04:49:21PM +0800, Zhu, Lingshan wrote:
> 
> 
> 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

OK as in there will be a thread for addressing VM suspend or OK as in
it's not really of interest?

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