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

[Amit Shah <amit.shah@redhat.com>]

(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, 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