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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
