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

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

 



Chris Wright wrote:

* Zachary Amsden ([email protected]) 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux