[RFC] First (incomplete) cut of Xen paravirt binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux