1995-03-16 18:17:34 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 1995 Bruce D. Evans.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. Neither the name of the author nor the names of contributors
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
* without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
1999-08-28 01:08:13 +00:00
|
|
|
* $FreeBSD$
|
1995-03-16 18:17:34 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _MACHINE_MD_VAR_H_
|
|
|
|
#define _MACHINE_MD_VAR_H_
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Miscellaneous machine-dependent declarations.
|
|
|
|
*/
|
|
|
|
|
2003-04-04 17:29:55 +00:00
|
|
|
extern long Maxmem;
|
2003-11-17 08:58:16 +00:00
|
|
|
extern u_int basemem;
|
2003-04-04 17:29:55 +00:00
|
|
|
extern int busdma_swi_pending;
|
2003-01-08 16:35:59 +00:00
|
|
|
extern u_int cpu_exthigh;
|
1998-07-11 05:59:35 +00:00
|
|
|
extern u_int cpu_feature;
|
2004-06-08 01:02:52 +00:00
|
|
|
extern u_int cpu_feature2;
|
|
|
|
extern u_int amd_feature;
|
2005-10-14 22:52:01 +00:00
|
|
|
extern u_int amd_feature2;
|
2008-10-21 00:17:55 +00:00
|
|
|
extern u_int amd_pminfo;
|
2009-01-12 19:17:35 +00:00
|
|
|
extern u_int via_feature_rng;
|
|
|
|
extern u_int via_feature_xcrypt;
|
2003-01-22 18:18:45 +00:00
|
|
|
extern u_int cpu_fxsr;
|
1998-07-11 05:59:35 +00:00
|
|
|
extern u_int cpu_high;
|
|
|
|
extern u_int cpu_id;
|
2006-06-19 22:36:01 +00:00
|
|
|
extern u_int cpu_mxcsr_mask;
|
2003-01-22 18:18:45 +00:00
|
|
|
extern u_int cpu_procinfo;
|
2005-10-14 22:52:01 +00:00
|
|
|
extern u_int cpu_procinfo2;
|
1995-03-16 18:17:34 +00:00
|
|
|
extern char cpu_vendor[];
|
2008-11-26 19:25:13 +00:00
|
|
|
extern u_int cpu_vendor_id;
|
1995-03-16 18:17:34 +00:00
|
|
|
extern char kstack[];
|
Mega-commit for Linux emulator update.. This has been stress tested under
netscape-2.0 for Linux running all the Java stuff. The scrollbars are now
working, at least on my machine. (whew! :-)
I'm uncomfortable with the size of this commit, but it's too
inter-dependant to easily seperate out.
The main changes:
COMPAT_LINUX is *GONE*. Most of the code has been moved out of the i386
machine dependent section into the linux emulator itself. The int 0x80
syscall code was almost identical to the lcall 7,0 code and a minor tweak
allows them to both be used with the same C code. All kernels can now
just modload the lkm and it'll DTRT without having to rebuild the kernel
first. Like IBCS2, you can statically compile it in with "options LINUX".
A pile of new syscalls implemented, including getdents(), llseek(),
readv(), writev(), msync(), personality(). The Linux-ELF libraries want
to use some of these.
linux_select() now obeys Linux semantics, ie: returns the time remaining
of the timeout value rather than leaving it the original value.
Quite a few bugs removed, including incorrect arguments being used in
syscalls.. eg: mixups between passing the sigset as an int, vs passing
it as a pointer and doing a copyin(), missing return values, unhandled
cases, SIOC* ioctls, etc.
The build for the code has changed. i386/conf/files now knows how
to build linux_genassym and generate linux_assym.h on the fly.
Supporting changes elsewhere in the kernel:
The user-mode signal trampoline has moved from the U area to immediately
below the top of the stack (below PS_STRINGS). This allows the different
binary emulations to have their own signal trampoline code (which gets rid
of the hardwired syscall 103 (sigreturn on BSD, syslog on Linux)) and so
that the emulator can provide the exact "struct sigcontext *" argument to
the program's signal handlers.
The sigstack's "ss_flags" now uses SS_DISABLE and SS_ONSTACK flags, which
have the same values as the re-used SA_DISABLE and SA_ONSTACK which are
intended for sigaction only. This enables the support of a SA_RESETHAND
flag to sigaction to implement the gross SYSV and Linux SA_ONESHOT signal
semantics where the signal handler is reset when it's triggered.
makesyscalls.sh no longer appends the struct sysentvec on the end of the
generated init_sysent.c code. It's a lot saner to have it in a seperate
file rather than trying to update the structure inside the awk script. :-)
At exec time, the dozen bytes or so of signal trampoline code are copied
to the top of the user's stack, rather than obtaining the trampoline code
the old way by getting a clone of the parent's user area. This allows
Linux and native binaries to freely exec each other without getting
trampolines mixed up.
1996-03-02 19:38:20 +00:00
|
|
|
extern char sigcode[];
|
2002-10-25 19:10:58 +00:00
|
|
|
extern int szsigcode;
|
Introduce minidumps. Full physical memory crash dumps are still available
via the debug.minidump sysctl and tunable.
Traditional dumps store all physical memory. This was once a good thing
when machines had a maximum of 64M of ram and 1GB of kvm. These days,
machines often have many gigabytes of ram and a smaller amount of kvm.
libkvm+kgdb don't have a way to access physical ram that is not mapped
into kvm at the time of the crash dump, so the extra ram being dumped
is mostly wasted.
Minidumps invert the process. Instead of dumping physical memory in
in order to guarantee that all of kvm's backing is dumped, minidumps
instead dump only memory that is actively mapped into kvm.
amd64 has a direct map region that things like UMA use. Obviously we
cannot dump all of the direct map region because that is effectively
an old style all-physical-memory dump. Instead, introduce a bitmap
and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that
allow certain critical direct map pages to be included in the dump.
uma_machdep.c's allocator is the intended consumer.
Dumps are a custom format. At the very beginning of the file is a header,
then a copy of the message buffer, then the bitmap of pages present in
the dump, then the final level of the kvm page table trees (2MB mappings
are expanded into a 4K page mappings), then the sparse physical pages
according to the bitmap. libkvm can now conveniently access the kvm
page table entries.
Booting my test 8GB machine, forcing it into ddb and forcing a dump
leads to a 48MB minidump. While this is a best case, I expect minidumps
to be in the 100MB-500MB range. Obviously, never larger than physical
memory of course.
minidumps are on by default. It would want be necessary to turn them off
if it was necessary to debug corrupt kernel page table management as that
would mess up minidumps as well.
Both minidumps and regular dumps are supported on the same machine.
2006-04-21 04:24:50 +00:00
|
|
|
extern uint64_t *vm_page_dump;
|
|
|
|
extern int vm_page_dump_size;
|
2003-11-17 08:58:16 +00:00
|
|
|
|
2002-03-20 05:48:58 +00:00
|
|
|
typedef void alias_for_inthand_t(u_int cs, u_int ef, u_int esp, u_int ss);
|
2001-09-12 08:38:13 +00:00
|
|
|
struct thread;
|
1995-03-16 18:17:34 +00:00
|
|
|
struct reg;
|
1998-09-14 22:43:40 +00:00
|
|
|
struct fpreg;
|
1999-07-09 04:16:00 +00:00
|
|
|
struct dbreg;
|
Introduce minidumps. Full physical memory crash dumps are still available
via the debug.minidump sysctl and tunable.
Traditional dumps store all physical memory. This was once a good thing
when machines had a maximum of 64M of ram and 1GB of kvm. These days,
machines often have many gigabytes of ram and a smaller amount of kvm.
libkvm+kgdb don't have a way to access physical ram that is not mapped
into kvm at the time of the crash dump, so the extra ram being dumped
is mostly wasted.
Minidumps invert the process. Instead of dumping physical memory in
in order to guarantee that all of kvm's backing is dumped, minidumps
instead dump only memory that is actively mapped into kvm.
amd64 has a direct map region that things like UMA use. Obviously we
cannot dump all of the direct map region because that is effectively
an old style all-physical-memory dump. Instead, introduce a bitmap
and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that
allow certain critical direct map pages to be included in the dump.
uma_machdep.c's allocator is the intended consumer.
Dumps are a custom format. At the very beginning of the file is a header,
then a copy of the message buffer, then the bitmap of pages present in
the dump, then the final level of the kvm page table trees (2MB mappings
are expanded into a 4K page mappings), then the sparse physical pages
according to the bitmap. libkvm can now conveniently access the kvm
page table entries.
Booting my test 8GB machine, forcing it into ddb and forcing a dump
leads to a 48MB minidump. While this is a best case, I expect minidumps
to be in the 100MB-500MB range. Obviously, never larger than physical
memory of course.
minidumps are on by default. It would want be necessary to turn them off
if it was necessary to debug corrupt kernel page table management as that
would mess up minidumps as well.
Both minidumps and regular dumps are supported on the same machine.
2006-04-21 04:24:50 +00:00
|
|
|
struct dumperinfo;
|
1995-03-16 18:17:34 +00:00
|
|
|
|
2002-03-20 05:48:58 +00:00
|
|
|
void busdma_swi(void);
|
|
|
|
void cpu_setregs(void);
|
|
|
|
void doreti_iret(void) __asm(__STRING(doreti_iret));
|
|
|
|
void doreti_iret_fault(void) __asm(__STRING(doreti_iret_fault));
|
Introduce minidumps. Full physical memory crash dumps are still available
via the debug.minidump sysctl and tunable.
Traditional dumps store all physical memory. This was once a good thing
when machines had a maximum of 64M of ram and 1GB of kvm. These days,
machines often have many gigabytes of ram and a smaller amount of kvm.
libkvm+kgdb don't have a way to access physical ram that is not mapped
into kvm at the time of the crash dump, so the extra ram being dumped
is mostly wasted.
Minidumps invert the process. Instead of dumping physical memory in
in order to guarantee that all of kvm's backing is dumped, minidumps
instead dump only memory that is actively mapped into kvm.
amd64 has a direct map region that things like UMA use. Obviously we
cannot dump all of the direct map region because that is effectively
an old style all-physical-memory dump. Instead, introduce a bitmap
and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that
allow certain critical direct map pages to be included in the dump.
uma_machdep.c's allocator is the intended consumer.
Dumps are a custom format. At the very beginning of the file is a header,
then a copy of the message buffer, then the bitmap of pages present in
the dump, then the final level of the kvm page table trees (2MB mappings
are expanded into a 4K page mappings), then the sparse physical pages
according to the bitmap. libkvm can now conveniently access the kvm
page table entries.
Booting my test 8GB machine, forcing it into ddb and forcing a dump
leads to a 48MB minidump. While this is a best case, I expect minidumps
to be in the 100MB-500MB range. Obviously, never larger than physical
memory of course.
minidumps are on by default. It would want be necessary to turn them off
if it was necessary to debug corrupt kernel page table management as that
would mess up minidumps as well.
Both minidumps and regular dumps are supported on the same machine.
2006-04-21 04:24:50 +00:00
|
|
|
void dump_add_page(vm_paddr_t);
|
|
|
|
void dump_drop_page(vm_paddr_t);
|
2004-06-08 01:02:52 +00:00
|
|
|
void initializecpu(void);
|
2002-03-20 05:48:58 +00:00
|
|
|
void fillw(int /*u_short*/ pat, void *base, size_t cnt);
|
2004-03-31 02:03:49 +00:00
|
|
|
void fpstate_drop(struct thread *td);
|
2004-04-11 04:26:58 +00:00
|
|
|
int is_physical_memory(vm_paddr_t addr);
|
2003-11-17 08:58:16 +00:00
|
|
|
int isa_nmi(int cd);
|
2004-03-31 02:03:49 +00:00
|
|
|
void pagecopy(void *from, void *to);
|
|
|
|
void pagezero(void *addr);
|
2003-05-01 01:05:25 +00:00
|
|
|
void setidt(int idx, alias_for_inthand_t *func, int typ, int dpl, int ist);
|
2004-01-29 00:05:03 +00:00
|
|
|
int user_dbreg_trap(void);
|
Introduce minidumps. Full physical memory crash dumps are still available
via the debug.minidump sysctl and tunable.
Traditional dumps store all physical memory. This was once a good thing
when machines had a maximum of 64M of ram and 1GB of kvm. These days,
machines often have many gigabytes of ram and a smaller amount of kvm.
libkvm+kgdb don't have a way to access physical ram that is not mapped
into kvm at the time of the crash dump, so the extra ram being dumped
is mostly wasted.
Minidumps invert the process. Instead of dumping physical memory in
in order to guarantee that all of kvm's backing is dumped, minidumps
instead dump only memory that is actively mapped into kvm.
amd64 has a direct map region that things like UMA use. Obviously we
cannot dump all of the direct map region because that is effectively
an old style all-physical-memory dump. Instead, introduce a bitmap
and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that
allow certain critical direct map pages to be included in the dump.
uma_machdep.c's allocator is the intended consumer.
Dumps are a custom format. At the very beginning of the file is a header,
then a copy of the message buffer, then the bitmap of pages present in
the dump, then the final level of the kvm page table trees (2MB mappings
are expanded into a 4K page mappings), then the sparse physical pages
according to the bitmap. libkvm can now conveniently access the kvm
page table entries.
Booting my test 8GB machine, forcing it into ddb and forcing a dump
leads to a 48MB minidump. While this is a best case, I expect minidumps
to be in the 100MB-500MB range. Obviously, never larger than physical
memory of course.
minidumps are on by default. It would want be necessary to turn them off
if it was necessary to debug corrupt kernel page table management as that
would mess up minidumps as well.
Both minidumps and regular dumps are supported on the same machine.
2006-04-21 04:24:50 +00:00
|
|
|
void minidumpsys(struct dumperinfo *);
|
1995-03-16 18:17:34 +00:00
|
|
|
|
|
|
|
#endif /* !_MACHINE_MD_VAR_H_ */
|