On Friday 28 July 2006 21:46, Zachary Amsden wrote: > Jeremy Fitzhardinge wrote > > This all makes me think it would be more awkward than helpful to have > > the Xen boot path go through the normal startup_32 path. > > > > If you move the CPUID code out of head.S into C, it gets a lot cleaner: It's a good idea. x86-64 does that too. It has a C head64.c as a wrapper before start_kernel that does various early initializations. So head32.c would make sense. Checking if the code is already in ring != 0 and skipping most of head.S and then calling out to a table of paravirtops initialization functions in head32.c would sound like a reasonable clean solution to me. Ok longer term if SVM/VT support becomes more wide spread and even para guests can run in ring 0 this might need to be changed again, but it would be easy to add a suitable test later then. > Why do you insist that Xen have a separate kernel entry point? > Publishing and maintaining multiple entry points is messy. Agreed. > You'll get to run the hypervisor > specific code a few instructions later, when we call out to fill in the > paravirt-ops table based on %ebx. And then you can write paravirt_ops > hooks for the things Xen has changed - command line, physical e820 map, > and do everything in C-code along the standard Linux startup path. Xen shouldn't change it. The Xen paravirt early init function should just put them into the places the kernel expects them from ordinary head.S -Andi
