Subject: Re: Small changes to libxc (save/restore part 4)
To: None <port-xen@NetBSD.org>
From: Jed Davis <firstname.lastname@example.org>
Date: 09/12/2005 23:16:49
Manuel Bouyer <email@example.com> writes:
> On Thu, Sep 08, 2005 at 12:55:53AM -0400, Jed Davis wrote:
>> Save/restore of a NetBSD domU would be nicer, but I'm not there
> I've not looked at this in details yet. It shouldn't need much for a domU
> that doens't have access to physical devices. A domU with physical devices
> would probably require to save/restore the device's setups, which probably
> requires a MI framework (not much different from what is needed for e.g.
> ACPI suspend/resume).
With no physical devices: I have looked at the details, or rather at
Linux's implementation of them, and I don't yet understand how to
translate: all of irq_suspend() and irq_resume(), parts of
time_resume(), and what needs to be done to fix up the phys-to-mach
map afterwards. More staring at code might make this clearer. The
rest of it seems to be a SMOP.
With physical devices, I don't see Linux trying to do anything about
them, which may just mean that nobody ever tried save/restore/migrate
in that case.
> For live migration, I don't know if there is additionnal support
> needed on the domU's side, or if the hypervisor does all the extra work
> (from what I remember, for a live migration, the domU's memory is copyed
> while the domU's kernel is still running. Then the domU is suspended and
> only pages that have been changed are transfered again).
That's all in the hypervisor and xfrd, from what I've seen of it; the
underlying functionality looked to be related to that used for shadow
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))