This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH, experimental] i386 Allow the fixmap to be reloca

To: Chris Wright <chrisw@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH, experimental] i386 Allow the fixmap to be relocated at boot time
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Fri, 05 Aug 2005 17:09:30 -0700
Cc: virtualization@xxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Sat, 06 Aug 2005 00:09:13 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050805234655.GY7762@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <42F3F61F.30305@xxxxxxxxxx> <20050805234655.GY7762@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
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:

       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).


Xen-devel mailing list