Re: [RFC, PATCH 5/5] Paravirt_ops export.patch

[Zachary Amsden <zach@vmware.com>]

Eric W. Biederman wrote:
>> Yes, we still do late paravirtualization.  My point is that because of that, you
>> can't just link once and be done with it - you must relink the paravirt-ops
>> later, which is more complex than a one time pre-execution link.
>>     
>
> Then if it is causing problems and making the code more complex (and it sounds
> like it is) please let's get rid of late paravirtualization.
>
> arch/i386 is in bad enough shape with tons of unnecessary special cases.
> We don't need the paravirtualization support adding more.
>   

Late paravirtualization is not causing problems and making the code more 
complex, in fact it is making it simpler.  The fact that we don't need 
to intrude in the boot process at all, but can let the code run without 
inhibition and 100's of special hooks is saving a lot of complexity.  
Otherwise, we would need to dissect head.S even further with custom junk 
for VMI, including probing for ROMs and other things that are just 
naturally easier once you have basic kernel architecture like physical 
mapping, PAE-ness and memory management in place.  Paravirtualizing the 
init code to set both non-PAE and PAE ptes from non-PAE mode (see 
boot_ioremap.c) would be one such grotesque and unwarranted violation.

My point is that if we were to use a linker type approach, it needs to 
be done before the first instruction of the kernel (in particular, 
before the first cpuid ever gets run); this makes it tempting to do in 
some weird assembly goo in head.S, instead of doing it in proper C code 
that can be reused later on.  Doing it in C would be better coding 
practice, it just requires more effort to avoid taking shortcuts (to 
work around the non-C starting environment).

Zach