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.
