PR/38699 CVS commit: [netbsd-6] src/sys/arch

["Jeff Rizzo" <riz%netbsd.org@localhost>]

The following reply was made to PR port-xen/38699; it has been noted by GNATS.

From: "Jeff Rizzo" <riz%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/38699 CVS commit: [netbsd-6] src/sys/arch
Date: Thu, 23 Feb 2012 21:17:25 +0000

 Module Name:   src
 Committed By:  riz
 Date:          Thu Feb 23 21:17:25 UTC 2012
 
 Modified Files:
        src/sys/arch/x86/x86 [netbsd-6]: pmap.c
        src/sys/arch/xen/x86 [netbsd-6]: x86_xpmap.c
 
 Log Message:
 Pull up following revision(s) (requested by bouyer in ticket #39):
        sys/arch/x86/x86/pmap.c: revision 1.170
        sys/arch/xen/x86/x86_xpmap.c: revision 1.40
 On Xen, there is variable-sized Xen data after the kernel's text+data+bss
 (this include the physical->machine table).
 (vaddr_t)(KERNBASE + NKL2_KIMG_ENTRIES * NBPD_L2) is after text+data+bss but,
 on a domU with lots of RAM (more than 4GB) (so large
 xpmap_phys_to_machine_mapping table) this can point to some of Xen's data
 setup at bootstrap (either the xpmap_phys_to_machine_mapping table,
 some page shared with the hypervisor, or our kernel page table). Using it for
 early_zerop will cause of these pages to be unmapped after bootstrap.
 This will cause a kernel page fault for the domU, either immediatly or
 eventually much later, depending on where early_zerop points to.
 To fix this, account for early_zerop when building the bootstrap pages,
 and its VA from here.
 May fix PR port-xen/38699
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.164.2.2 -r1.164.2.3 src/sys/arch/x86/x86/pmap.c
 cvs rdiff -u -r1.38.2.1 -r1.38.2.2 src/sys/arch/xen/x86/x86_xpmap.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.