[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]