Re: [PATCH, experimental] i386 Allow the fixmap to be relocated at boot time

[Zachary Amsden <zach@vmware.com>]

Chris Wright wrote:

>* Zachary Amsden (zach@vmware.com) wrote:
>  
>
>>This most curious patch allows the fixmap on i386 to be unfixed.  The 
>>result is that we can create a dynamically sizable hole at the top of 
>>kernel linear address space.  I know at least some virtualization 
>>developers are interested in being able to achieve this to achieve 
>>run-time sizing of a hole in which a hypervisor can live, or at least to 
>>test out the performance characteristics of different sized holes.
>>    
>>
>
>I've done it simpler with keeping it fixed but defined by the subarch.
>Patch is stupid simple (and untested).  Do you think there's a huge gain
>for dynamically sizing?
>

Your patch looks good, although the minimal change to subarch is to 
merely have __FIXADDR_TOP defined by the sub-architecture.  Is there any 
additional benefit to moving the fixmaps into the subarch - i.e. moving 
subarch-specific pieces out of mach-default?

I guess there is.  For example include/asm-i386/mach-visws/mach_fixmap.h 
could do this:

#define SUBARCH_FIXMAPS \
        FIX_CO_CPU,     /* Cobalt timer */ \
        FIX_CO_APIC,    /* Cobalt APIC Redirection Table */ \
        FIX_LI_PCIA,    /* Lithium PCI Bridge A */ \
        FIX_LI_PCIB,    /* Lithium PCI Bridge B */

Then include/asm-i386/fixmap.h includes <mach_fixmap.h>, for which the 
default is an empty define for SUBARCH_FIXMAPS.

And then you don't have to maintain the list of common fixmaps across 
the sub-architecture layer or uglify the top level fixmaps with SGI 
Visual Workstation support.

Also, it seems reasonable that people may want to poke holes in high 
linear space for other hypervisor projects, research, or performance 
reasons without having to build a custom sub-architecture just for 
that.  So I think there is some benefit to making the hole size a 
general configurable option (with defaults depending on the sub-arch you 
select).

I have no idea if the dynamic sizing has any performance impact yet, but 
it may be a big win in terms of flexibility.  I would be curious to hear 
more from the Xen core team (I know Ian mentioned he would like to try 
this out at one point in time).

Zach