I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen paravirt ops, does some CPUID setup which would normally be done in head.S, calls set_fixaddr_top(), and then calls the normal start_kernel(). These patches compile, but are completely untested (though I recently booted it native on qemu, so it isn't completely broken). The Xen entrypoints are very incomplete; so far I've only done the trivial ones, including the ones which end up just using the native nopara implementations (which I've exported out of paravirt.c). I'm about to start on implementing the more substantial paravirt ops relating to interrupts, segmentation, and everything else needed to get to a minimally functioning kernel. I also haven't really gone over the list of paravirt ops in detail to see if they're really what we want; I figure that will come up as I keep adapting Xen to the interface. But an obvious seems to be we should have explicit flush_tlb/multicast_flush_tlb calls rather than simply relying on reloading cr3. Comments? Does this look like the way we want to go? So far it has been coming together very nicely... J (Rusty, it would be convienient if you enabled .tar.gz/.zip downloading in the hg server: put "allow_archive = gz, zip" in the [web] part of hgrc.)
