[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] save/restore race

> save requires a valid arch.pfn_to_mfn_frame_list_list MFN. However,
> there is no guarantee that this is up to date, since a previous
> restore is considered complete as soon as the domain is unpaused:
>         if not paused:
>             dominfo.unpause()
>         dominfo.completeRestore(handler.store_mfn,
> It seems that Linux is being lucky here, in that rebuilding the MFNs
> the first thing it does after suspend(). On Solaris, it occurs
> later in the resume process due to constraints on locking within our
> code.
> This doesn't seem specific to migration either, a save just after a
> restore has completed can hit this race as far as I can see. I'm short
> on ideas that don't involve a new interface (like the domain writing
> back a xenstore value when it's done resuming). Suggestions?

Just ignore any new suspend request until you've got the frame list list

In the Linux code this is implicit as xenbus and even interrupts aren't
re-enabled until after this.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.