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] x86-64's contig_initmem_init

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] x86-64's contig_initmem_init
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 30 Aug 2005 15:19:29 +0200
Delivery-date: Tue, 30 Aug 2005 13:16:31 +0000
Envelope-to: www-data@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Not very long ago there was a change to this function appearantly to
make available the first megabyte of memory. While this is a nice
attempt, I wonder how this worked out for anyone not using shadow mode:

Since the initial allocation is provided as a read-write mapping, the
occasional use of memory from the corresponding physical range to
populate page tables (or descriptor tables) results on BUG_ON-s being
triggered in hypervisor.c because these pages then cannot be pinned
(after converting their phys-to-virt mapping to read-only they still
have the initial mapping left read-write, which prevents the necessary
type transition from happening).

While resolving this I wanted to avoid adding code to
make_page_readonly (much like i386 has a special case already, but
appearantly to deal with a different scenario), I wondered whether one
couldn't make these unused portions of the initial mapping readonly
during early setup; since I wasn't sure whether I'd encounter any
problems with that I didn't attempt to do so, yet, and rather reverted
the original change.

Finally I wonder why this first Mb was taken care about, but the
potentially larger area at the end of the initial allocation (which to
my understanding is currently lost, too) wasn't. And I am having the
understanding that the respective memory ranges for i386 are also lost.


Xen-devel mailing list