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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 26/2/08 11:27, "James Harper" <james.harper@bendigoit.com.au>
wrote:
> *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...
This doesn''t happen with Linux I''m pretty sure, as accesses to
a single
block are serialised at a higher level.

 -- Keir



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

> On 26/2/08 11:27, "James Harper"
<james.harper@bendigoit.com.au>
wrote:
> 
> > *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...
> 
> This doesn''t happen with Linux I''m pretty sure, as
accesses to a
single
> block are serialised at a higher level.
I think the higher level doesn''t have visibility to this...

. Frontend sends A, B & C to Backend
. Backend completes the requests and sends responses to Frontend
. Suspend happens before Frontend notices the responses
. Time passes...
. Resume
. Frontend is torn down on resume
. Frontend reissues uncompleted (as far as it knows) requests A, B & C

Obviously I don''t have a very good understanding of the suspend/resume
operation yet, but I can''t see anything that waits for responses for
outstanding requests, so I can''t see anything that would prevent my
hypothetical situation from occurring. Unless you are referring to
caching when you talk about ''higher level''?

I also can''t imagine a situation where it is going to matter though,
except _maybe_ a migrate on a DomU connected to a cluster filesystem...

James

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

On 26/2/08 12:00, "James Harper" <james.harper@bendigoit.com.au>
wrote:
>> This doesn''t happen with Linux I''m pretty sure, as
accesses to a
> single
>> block are serialised at a higher level.
> 
> I think the higher level doesn''t have visibility to this...
> 
> . Frontend sends A, B & C to Backend
What I mean is, Linux would not create such a set of requests A, B & C in
the first place. Linux will lock out the page from other I/Os when the first
read or write request is issued.

 -- Keir



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

> > I think the higher level doesn''t have visibility to this...
> >
> > . Frontend sends A, B & C to Backend
> 
> What I mean is, Linux would not create such a set of requests A, B & C
in
> the first place. Linux will lock out the page from other I/Os when the
> first read or write request is issued.
Understood. My only vague concern was with cluster filesystems, but by
the sounds of it it won''t be a problem.

Thanks

James


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