Rusty Russell <rusty at rustcorp.com.au> writes: >> It isn't clear to me who sets %ebx in your proposal. If you're >> suggesting that the hypervisors do it, it seems like a bit presumptuous >> to have a specific mechanism just for us. If you're saying that a >> common PV startup function needs to try to sniff what hypervisor its >> under, that seems very tricky, particularly since we can't take any >> faults at that point. > > Naah, the hypervisor sets %ebx. That's 0 for you, so it's all fine. > >> Its also possible that a hypervisor is fully virtualizing, so that boot >> proceeds via the normal startup_32 path, but at some later point the >> guest can register some pv_ops for better performance. (Similar to your >> idea for an in-kernel modular hypervisor.) > > Indeed, and that in no way conflicts with this entry point. The linux 32bit entry point is well defined. %ebx holds the cpu number from a bootloader it must be 0. %esi holds a pointer to the linux parameter blob, that is usually filled in with BIOS calls. If you need hypervisor information at boot time and none of the existing parameters in %esi will suffice, bump the boot protocol version and allocate another variable. And find that variable through %esi. It's an extra instruction but not too hard. Bumping the boot protocol is probably desirable anyway because it will all reporting that the kernel can be paravirtualized. /sbin/kexec ultimately has to operate in all of these environments, and it would be insane if the bootloader had to be modified for a different calling convention for each environment. If another bootloader is being used it can be taught how to impedance match between linux and the hypervisor environment, that is the job of a bootloader. For those environments where paravirtualization is just an optimization we mostly likely want the detection to happen in arch/i386/boot/setup.S if it needs to happen early. As small food for thought. There is currently work in progress to place an ELF header at the start of the bzImage to export the 32bit entry point, and to export the capability of the kernel being relocated. Hopefully we can get to the point we can boot a standard bzImage kernel on the hypervisors as well. Even if we can't use the 16bit entry point. Eric