This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] live saving of domU

To: Andres Lagar Cavilla <andreslc@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] live saving of domU
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Wed, 10 May 2006 16:05:50 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 May 2006 14:07:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44625027.3090804@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1FdtIP-0000Id-VQ@host-192-168-0-1-bcn-london> <44623B92.7050300@xxxxxxxxxxxxxx> <446241C5.1030004@xxxxxxxxxx> <44625027.3090804@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mail/News 1.5 (X11/20060309)
Andres Lagar Cavilla wrote:
My understanding is that the guest only canonicalizes the store and console mfn's and places them on the shared info frame which is passed to the suspend hypercall. The rest of the canonicalizations are done by dom0 user-space code (xc_linux_save).

Sort of. When you pause a domain, it could be doing something like a PTE update in which case it has a PFN in a register (or on the stack somewhere). Part of the reason for having a suspend entry point in the kernel is to ensure that we're in a consistent state.

Does the guest kernel do anything beyond what's in __do_suspend in reboot.c?

Nothing that isn't reachable from that function.

The guest never really shuts down: it issues the suspend hypercall and waits for it to return. This could happen months later when the domain is resumed :) The suspend hypercall executing in xen is the one that pauses all vcpus and kills the domain.

Actually, take a look at what HYPERVISOR_suspend is:

It's just a shutdown op.

But it doesn't have to be. The hypercall could only pause the domain, and let the user-space tools unpause (no 's' bit -> no domain/devices teardown) when checkpointing is over. The guest kernel can't tell the difference: it returns from the hypercall and life goes on, as long as the devices are still there. That's what I was referring to with:

It could, but you have a number of other problems you have to solve. How do you signal to userspace that the domain is suspended? You could introduce another VIRQ perhaps or extend the state. The __do_suspend path supposes that the devices are being cycled too. You either need Xend to participate in this process. How devices interact would need some careful thinking.

Is it feasible to use a different hypercall that pauses the domain but doesn't kill it, and once xc_linux_save is done checkpointing have it issue a dom0_op that unpauses the domain?

A domain is "killed" with a dom0_op of domain_destroy which is invoked by Xend. The problem with checkpointing is that once the 's' bit has been set on a domain, there's no way to unset that bit.

As I said a few lines up, let's not set the 's' bit for lightweight checkpoints. This is likely to cause a lot of special casing for xend/xenstore, right?

Yeah, there's a lot of bits of userspace code that would be effected. I hope this isn't disparaging, I certainly think it's worth the effort.


Anthony Liguori


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>