Manuel Bouyer <bouyer@antioche.eu.org> 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
>> yet.
>
> 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
page tables.

-- 
(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)))))