Rusty's Bleeding Edge Page

lguest is in the -mm tree, although Andi doesn't think it should get into 2.6.21. I disagree, since it's fairly self-contained: kvm went in then was rewritten, but OTOH, that didn't go through Andi IIRC.

The lkml peer review has been great: Jens found a block driver bug (fixing that more than doubled the block speed), and Herbert found a network driver bug. Andi, in particular, walked through the patch and made numerous comments, most of which I acted upon.

The disturing idea came out of the x86-64 lguest port proposal on the virtualization mailing lists. Andi and Zach waved the idea of how to do lguest on x86-64 at me at LCA, but I was distracted. Having thought about it, I think it's doable: use read-only pages for the highmem area and not segment limits (which is not available on many x86-64 systems apparently). More disturbing is the idea that this is how I should have done the 32-bit version of lguest.

What does this mean? Well, I wouldn't have to futz with segments, and the magic restoration of 4G segments for threaded userspace code. This would get rid of the most complex part of lguest. Secondly, since I'd need a whole scratch page, I'd have plenty of stack room to handle NMIs (currently oprofile reboots my machine when an lguest is running because we do *not* handle nested interrupts). Finally, it would make the x86-64 port fairly straight-forward.

The downside is that it's back to hacking on the low-level switch code. This was the slowest part of development, and something I thought I'd put behind me: now it was surely about optimizations and features! Plus, all that learning about segments: wasted!

Intel kindly offer free x86 reference books if you ask, and they arrived today. Perhaps this is a sign?

[/tech] permanent link