[Xen-devel] Suspend/Save a machine under HVM (questions for implementation in Win GPL PV driveres)

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

Are there any documents describing how an 'xm save' should work under
HVM? I would like to add this functionality to the Windows GPL PV
drivers.

Starting with the 'unmodified drivers' code for Linux, I think it goes
something like this (ignoring the failure or cancelled path for now):

. Dom0 writes 'suspend' to 'shutdown' in xenstore
. DomU agrees to the suspend by doing ?
. DomU suspends each device
  . This appears to almost be a no-op for vbd and vif?
. DomU suspends xenbus
  . Again, this pretty much looks like a no-op
. DomU calls preempt_disable()
. DomU disables the HVM IRQ
. DomU waits until all CPU's are idling
. DomU disables all IRQs on the local CPU
. DomU calls HYPERVISOR_shutdown with an argument of SHUTDOWN_suspend

At this point the machine is suspended. Resume is the reversal of
suspend, with the following exceptions:
. vbd just re-issues all the outstanding requests to the backend *1
. vif just tells the operating system that all outstanding requests were
successful? Or maybe that they failed? I can't exactly find this in the
code, but I'm guessing that that is probably okay. Either that or we
re-send them, but if the duration of the suspend is anything other than
very short the packets are no longer valid anyway

*1 what happens if the outstanding requests were:
A - Read value from sector 42
B - Write value X to sector 42
C - Read value from sector 42

If all the requests had been completed by the backend but not yet
processed on the frontend, then when the operations are retransmitted,
operation A is going to return the value of X, instead of whatever was
previously in sector 42. Maybe this doesn't matter...

James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel