CVS log for src/sys/arch/amd64/conf/kern.ldscript.Xen

Up to [cvs.NetBSD.org] / src / sys / arch / amd64 / conf

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

put .note.Xen into PT_NOTE

this is where grub 2.02 and possibly other things expect
to find it.
Fixes booting with grub2 on prgmr.com.

update Xen ldscript to add kASan .ctors section, so that Xen kernel with
enabled KASAN option at least compiles; no promises on it actually working
though

Sync with HEAD

Sync the ld scripts:

 * Force a PAGE_SIZE alignment of .bss on i386. Normally that's not
   required since the bootloader ensures page alignment, but let's be
   safe. Same on Xen-i386.

 * Fill the .text section padding with int3 instructions on Xen kernels,
   to prevent FALLTHROUGHs if a pointer goes crazy, same as native.

follow change in rev. 1.22 of kern.ldscript and apply same fix for xen
ldscript too, but using just regular PAGE_ALIGN alignment:

"""
Fix a pretty dumb mistake I made in r1.22: the alignment needs to be in the
bss, otherwise the bootloader will use memory before __kernel_end and give
a wrong start pa to the kernel.
"""

this got broke by amd64/locore.S rev. 1.141 which removed an unused variable
which forced the alignment

this fixes ps/bt in ddb to be able to find symbols and hence PR port-xen/53056

Pull up the following revisions, requested by maxv in ticket #603:

	amd64/conf/kern.ldscript      1.25 (patch)
	amd64/conf/kern.ldscript.Xen  1.14 (patch)
	i386/conf/kern.ldscript       1.21 (patch)
	i386/conf/kern.ldscript.Xen   1.15 (patch)
	x86/include/cpufunc.h         1.24 (patch)
	x86/x86/patch.c               1.25 (partial) 1.26 (partial)

Backport x86_hotpatch.

Implement a real hotpatch feature.

Define a HOTPATCH() macro, that puts a label and additional information
in the new .rodata.hotpatch kernel section. In patch.c, scan the section
and patch what needs to be. Now it is possible to hotpatch the content of
a macro.

SMAP is switched to use this new system; this saves a call+ret in each
kernel entry/exit point.

Many other operating systems do the same.

update from HEAD

Sync with HEAD

Sync with HEAD

Align the segments properly, and split text+rodata in two separate segments
on Xen.

Sync with HEAD

Xen therefore uses x86/db_memrw.c, as I suspected. Define __rodata_start
in the Xen ld scripts, so that it can compile. We put the __rodata_start
definition right before __data_start, for it to appear as dead code, since
the rodata segment is not yet mapped independently on Xen.

KNF the Xen ld scripts on x86.

Sync with HEAD

Fix previous; do include assym.h.

Replace COHERENCY_UNIT in ldscript.

Don't need to specify OUTPUT_FORMAT/OUTPUT_ARCH in linker scripts.

Simplify these by relocating only .text.

Indent with 2 spaces.

Revert previous per joerg@'s request.

According to him, exposing .data.{read_mostly,cacheline_aligned} is
intentional so that people can easily see which variables are optimized.

amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned} sections

More sync fixes. And add the mbr_gpt files.

Sync with HEAD

Sync with HEAD.

sync with head.

sync with head

Add __cacheline_aligned and __read_mostly annotations.

These annotations help to mitigate false sharing on multiprocessor
systems.

Variables annotated with __cacheline_aligned are placed into the
.data.cacheline_aligned section in the kernel. Each item in this
section is aligned on a cachline boundary - this avoids false
sharing. Highly contended global locks are a good candidate for
__cacheline_aligned annotation.

Variables annotated with __read_mostly are packed together tightly
into a .data.read_mostly section in the kernel. The idea here is that
we can pack infrequently modified data items into a cacheline and
avoid having to purge the cache, which would happen if read mostly
data and write mostly data shared a cachline. Initialisation variables
are a prime candiate for __read_mostly annotations.

sync with HEAD

Sync with HEAD.

sync with head

Sync with HEAD.

Sync with HEAD. amd64 Xen support needs testing.

file kern.ldscript.Xen was added on branch matt-armv6 on 2008-01-09 01:44:51 +0000

file kern.ldscript.Xen was added on branch yamt-lazymbuf on 2007-12-07 17:24:03 +0000

file kern.ldscript.Xen was added on branch vmlocking on 2007-12-03 19:02:47 +0000

file kern.ldscript.Xen was added on branch jmcneill-pm on 2007-11-27 19:35:31 +0000

Pull up the bouyer-xenamd64 branch to HEAD. This brings in amd64 support
to NetBSD/Xen, both Dom0 and DomU.

Finish sync with HEAD. Especially use the new x86 pmap for xenamd64.
For this:
- rename pmap_pte_set() to pmap_pte_testset()
- make pmap_pte_set() a function or macro for non-atomic PTE write
- define and use pmap_pa2pte()/pmap_pte2pa() to read/write PTE entries
- define pmap_pte_flush() which is a nop in x86 case, and flush the
  MMUops queue in the Xen case

amd64 (aka x86-64) support for Xen. Based on the OpenBSD port done by
Mathieu Ropert in 2006.
DomU-only for now. An INSTALL_XEN3_DOMU kernel with a ramdisk will boot to
sysinst if you're lucky. Often it panics because a runable LWP has
a NULL stack (really, it's all of l->l_addr which is has been zeroed out
while the process was on the queue !)
TODO:
- bug fixes :)
- Most of the xpq_* functions should be shared with xen/i386
- The xen/i386 assembly bootstrap code should be remplaced with the C
  version in xenamd64/amd64/xpmap.c
- see if a config(5) trick could allow to merge xenamd64 back to xen or amd64.

file kern.ldscript.Xen was initially added on branch bouyer-xenamd64.