| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH, experimental] i386 Allow the fixmap to be reloca
Chris Wright wrote:
* Zachary Amsden (zach@xxxxxxxxxx) 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home