Re: Starting save/restore for port-xen - initial questions

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Tuesday 11 March 2008 11:40:46 Manuel Bouyer wrote:
> On Mon, Mar 10, 2008 at 11:38:18PM +0100, Jean-Yves Migeon wrote:
> > Hi list,
> >
> > As it is my first mail on this list, and, to some extent, the first
> > "big" one, I shall introduce myself: my name is Jean-Yves Migeon, a 24
> > year old french student (currently in Paris), who encountered NetBSD
> > during his studies in his school. I started as a self-taught system
> > administrator for the students network.
> >
> > For the sake of curiosity, I started to read books (and a bit of code)
> > dealing with kernel, to gain some understanding about its internals; but
> > consider me a complete kernel noobie.
> >
> > The current year in my scholarship has some time reserved for personal
> > work, termed a "project". I asked whether I could use this time to start
> > contributing to NetBSD; it was kindly  accepted. I ended up starting to
> > work for the suspend/resume functionality in port-xen, under the
> > supervision of Manuel Bouyer (bouyer@) and Stoned Elipot (seb@), who I
> > both thank for accepting this proposal.
>
> Well, it's great to have someone working on this :)

indeed.

[...]

> > Hence, I have some questions. Having extra pointers to areas in
> > /usr/src/sys/ (I am mostly relying on ctags right now...) would be of
> > great help. Note that I am not making any difference between "suspend"
> > and "save", and "resume" and "restore". Please correct me if I am wrong.
>
> this is correct. suspend/resume is the same as save/restore for Xen.
> The difference with a real hardware is that we may resume on a different
> hardware than one we did suspend (migration).

ACPI S3 support in Xen has been introduced in Xen 3.2.
So for real hardware suspend/resume with Xen, an update to Xen 3.2
is required.

> > - Same question goes for externally dependent mechanisms, like, TCP
> > connections, which will inevitably timeout if we suspend the domain for
> > a long time,
>
> Sure, but it'll be handled by the TCP stack. It's not different from
> suspending a laptop.

That's correct. But TCP connections should not drop on live migration.

> > - many files in port-xen already contain code dealing with save and
> > restore operations: xenbus, backend (xbd), grant tables (xengnt), ...
> > Can I use them as reference to understand the key differences between a
> > full domain start and a restore? *_attach() usually calls *_resume()
> > once it has finished its operations (see arch/xen/xen/xbd_xenbus.c:243
> > for example); I guess that this code was mainly tested in a
> > "traditional" boot up phase, and not with a restore operation. If no,
> > feel free to correct me. If yes, did the code using *_resume() land
> > somewhere?
>
> When I wrote these code, I started thinking about suspend/resume and
> tried to split the code required to boot appropriately. But for
> now it has only been tested for a full domain boot, and I'm not sure
> the split between attach and resume is 100% correct. This is one of the
> things to look at :)

You can test at runtime with xm block-attach/detach and xm 
network-attach/detach.

This is a lot easier to debug.

Christoph