Rusty Russell <rusty at rustcorp.com.au> writes: > On Sun, 2006-07-30 at 19:05 +0200, Andi Kleen wrote: >> > (1) We can make startup_32 work for every known and future reasonable >> > hypervisor as well as native, by testing if ring isn't 0 and paging is >> > enabled and jumping to the paravirt entry path. >> >> Somehow the right Hypervisor still needs to be discovered though >> so that the right paravirt ops can be installed. >> >> We would need a standard interface for this. > > Yes, that's %ebx here (0 == Xen): we call paravirts[%ebx]->init(). > > Of course if you do full virtualization and then later want to insert > paravirt_ops, you can just use the normal boot path (Zach has indicated > that VMWare will do this in the short to medium term anyway). > > FYI, here's the actual patch. > > Thanks! > Rusty. > > First cut (compiles, untested) of generic startup_paravirt entry point. > > 1) Each hypervisor type creates a paravirt_ops struct and puts an > agreed-on entry in the paravirts[] array. Strictly, this need > only have the init function populated. > > 2) The hypervisor type is handed through %ebx to the startup_paravirt > function at boot. Currently 0 = Xen 3.0, 1 = VMI. > > 3) The init function (called with all regs except for %ebx and %esp > intact), with first arg pointing to the paravirt_ops structure > we're using. This is responsible for overwriting the paravirt_ops: > a helper called initialize_ops_struct is provided. I have a fundamental problem with this patch. Don't we enter the kernel at: arch/i386/boot/compressed/head.S startup_32? Doesn't %ebx get stomped? Otherwise I think the concept is fine, the implementation just won't work. Eric
