Re: porting lguest to x86_64

[Rusty Russell <rusty@rustcorp.com.au>]

On Mon, 2007-02-12 at 12:29 -0500, Steven Rostedt wrote:
> Hi all,
> 
> Glauber and I have been looking into porting lguest over to the x86_64.
> We've spent the last couple of weeks just trying lguest out and seeing
> how far we can "force" it over to x86_64. This was more of just a
> learning experience to get our feet wet in lguest since we are still
> very green at it.  I also notice that lguest moves very fast (we were
> still working on drivers/lguest when I now see it has moved to
> arch/i386/lguest).

Yeah, sorry about that.  My very initial intention was to have x86-64
and PowerPC ports, but since the code is so arch-specific I decided that
it didn't make much sense at this point, so hence the move.

Plus, being in a single directory gives it that nice self-contained
feeling which makes upstream inclusion easier.

Now, at some point that decision might well be reversed...

> Anyway, we've decided that the work we have done so far was just a
> learning prototype and have thrown it out for some better ideas. But
> before getting too deep into coding, we want to ask the giants of lguest
> for their ideas, and their thoughts on what we want.

Well, there are many ways to write this.  Yours is very different,
that's for sure!

A few general points:
1) The entire point of the paravirt_ops infrastructure is to allow a
single kernel to adapt to different hypervisors at runtime.  This is a
real feature which should not be ignored, IMHO.  Also, the "modprobe and
go" model of host kernels is extremely attractive.  So changing
PAGE_OFFSET or what segments the kernel uses is not the trivial matter
it would otherwise be.

2) I would start really simple: no guest SMP, for example.  I would also
look hard at stealing KVM's mmu code: lguest's is much simpler, *but*
that's because it's only a simple 2-level.

3) The purpose of the high-loaded switcher code in lguest is to switch
the world back in a place where it can't be reached by the guest, due to
segment limits.  While this is not generally possible on x86-64, Andi
and Zach pointed out to me that a very similar approach is: use a
read-only page for this code, and a rw page to save & restore state.
When you go SMP for guests, you need a different page for each virtual
CPU of course, but that's later.  I haven't completely thought this
through, but it should work.

One benefit of this approach is that it *will* be v. v. similar to
32-bit lguest.  In fact, 32-bit lguest could probably be changed to use
the same technique without any real harm; indeed, it solves the problem
of 4G segments very nicely.... hm....

Cheers!
Rusty.