On Wed, 2006-07-26 at 10:56 -0700, Jeremy Fitzhardinge wrote: > 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(). Cool! I want to make three changes to this over time: 1) Copy the ops structure in the asm, based on value of %ebx (0 == xen, etc). Only copy the non-NULL entries, to make implementing ops simple (eg. Xen doesn't want to override all ops). Xen wants %esi, so I might have to move that to %eax: I'll see how it works out. 2) Call *paravirt_ops.init rather than hardcoded xen_start_kernel. 3) Rename from xen-head.S to paravirt-head.S. > 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. Yep, and I thought about set_tss_desc, rather than lower-level ops, because Xen doesn't want it at all. But see how you go.. > Comments? Does this look like the way we want to go? So far it has > been coming together very nicely... Agreed! > (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.) Done (your instructions were not quite right, but the man page worked wonders!). Thanks, Rusty. -- Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
