Re: [RFC PATCH] virtio: (Partially) enable suspend/resume support

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

On Mon, Nov 22, 2010 at 07:15:37PM +0530, Amit Shah wrote:
> (Adding Matthew Garrett and Vadim Rosenfeld)
> 
> On (Fri) Nov 05 2010 [12:15:36], Michael S. Tsirkin wrote:
> > I still don't see it.  why don't we reset on resume?
> > If there's a reset host must either discard or
> > flush out operations in progress.
> 
> OK, let me list how virtio-serial works, then let's see how Windows and
> Linux differ in their suspend/resume implementations and then discuss
> solutions.
> 
> virtio-serial, in its probe routine, exchanges some information over a
> control vq and per-port vqs -- the number of ports, the number of open
> ports, the names assigned to the ports, etc.
> 
> When Linux starts up, it goes about doing the regular init, calling the
> probe routine.  Later, when it detects there is a suspended image
> available, it restores that image.
> 
> After the image is restored, the vring counts in qemu reflect the
> transfer that's taken place in the probe routine, whereas the vring
> counts in the guest kernel reflect the pre-suspend values.
> 
> The Linux kernel's suspend/resume notifiers currently offer the
> following notifications:
> - Preparing to go to suspended state (tasks will be frozen now)
> - Preparing to restore the image saved at hibernate-time
> - Restore succeeded (called after user-space threads are thawed)
> 
> 
> What the Windows driver does is destroy all the virtqueues before
> suspend and re-init all of them on restore.  This works well, but in the
> Linux case, we don't have a notifier that gets called after restore
> succeeds and before user-space tasks are thawed,

Let's add one?

> which means for an open
> virtio-serial port, a userspace app doing non-stop writes may find the
> communication channel broken because the underlying vq vanished.
> 
> Windows has one problem with the balloon driver too -- inflate a
> balloon, hibernate.  Start the machine, restore image.  Windows thinks
> balloon is inflated.  qemu thinks it's deflated.  This can be solved by
> Windows providing a balloon size update to qemu but will most perhaps
> need a change to qemu.
> 
> For network ports, I guess it'll be the same situation - getting the
> network up before userspace notices.
> 
> 		Amit