Jeremy Fitzhardinge wrote:> Single entry pros: > > * simpler control flow? >Simpler to maintain the code. Maintaining multiple intertwined entry points is a mess. It used to be done for Visual workstation, and the code got merged back together. Here's a pretty easy thing to do: ENTRY(startup_32) #ifdef CONFIG_PARAVIRT movl %cs, %eax testl $0x3, %eax jnz pv_startup_32 #endif Now you don't need any special magic at all to register an alternate entry point.> cons: > > * requires "hypervisor sniffing" to work out what hypervisor we're under > o mandates setting %ebx to a magic constant? > * not possible to have hypervisor-specific setup before setting up > stacks, making calls, etc > > > Where do the ebx constants come from anyway? If they're provided by the > hypervisor itself, it means we need to have a registry of who's using > what number, right? We'd require them to all be unique (since > collisions would be disastrous), and also they need to be densely > allocated (single we're using them as an array index). >Why is registering these constants hard? I prefer the symmetry of having all vendors use the same entry method rather than encouraging ad-hoc hacks. Zach
Hi Rusty,
I had a look over your 011-paravirt-head.S.patch. I'm struggling to
come up with a list of any benefits over having separate entrypoints for
each hypervisor.
Multiple entry pros:
* allows maximum startup flexibility for any given hypervisor
* for Xen at least, it's pretty simple
* the "what hypervisor am I under" question is answered trivially
cons:
* small amount of duplicated code? (can be factored out into shared
functions)
* assumes each hypervisor has a distinct way of setting the entry
address
Single entry pros:
* simpler control flow?
cons:
* requires "hypervisor sniffing" to work out what hypervisor
we're under
o mandates setting %ebx to a magic constant?
* not possible to have hypervisor-specific setup before setting up
stacks, making calls, etc
Where do the ebx constants come from anyway? If they're provided by the
hypervisor itself, it means we need to have a registry of who's using
what number, right? We'd require them to all be unique (since
collisions would be disastrous), and also they need to be densely
allocated (single we're using them as an array index).
Rusty, could you explain your rationale a bit more?
J
> Zachary Amsden wrote: > The crazy string extraction Xen has to do to figure out hypervisor > features from the xen_guest section - which is a really bad idea. > Putting this in the kernel is unnecessary if you have a paravirt_ops > initialization function which can negotiate this information to the > hypervisor. Putting this code into Linux sets an extremely bad > precedent by encouraging ad-hoc, hypervisor specific sections > to be put > in the kernel. It is ugly, gratuitous, and unnecessary change to > Linux, Please fix your loader so this doesn't need to be part of the > maintained Linux code:Except that the domain builder needs to know most of this information to setup the guest correctly (initial pagetables, hypercall page) and to check compatibility (pae, version, features). I guess we could try to agree on a structure, but that would only hinder evolution. Christian