2005-01-06 23:35:40 +00:00
|
|
|
/*-
|
1994-05-24 10:09:53 +00:00
|
|
|
* Copyright (c) 1980, 1986, 1989, 1993
|
|
|
|
* The Regents of the University of California. All rights reserved.
|
|
|
|
* (c) UNIX System Laboratories, Inc.
|
|
|
|
* All or some portions of this file are derived from material licensed
|
|
|
|
* to the University of California by American Telephone and Telegraph
|
|
|
|
* Co. or Unix System Laboratories, Inc. and are reproduced herein with
|
|
|
|
* the permission of UNIX System Laboratories, Inc.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
* 4. Neither the name of the University nor the names of its contributors
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
* without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
|
|
|
|
*
|
1996-03-11 05:52:50 +00:00
|
|
|
* @(#)param.c 8.3 (Berkeley) 8/20/94
|
1994-05-24 10:09:53 +00:00
|
|
|
*/
|
|
|
|
|
2003-06-11 00:56:59 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
1996-03-02 18:24:13 +00:00
|
|
|
#include "opt_param.h"
|
2011-01-21 10:26:26 +00:00
|
|
|
#include "opt_msgbuf.h"
|
2001-07-26 23:04:03 +00:00
|
|
|
#include "opt_maxusers.h"
|
1996-01-04 20:29:06 +00:00
|
|
|
|
1994-05-24 10:09:53 +00:00
|
|
|
#include <sys/param.h>
|
2001-07-26 23:04:03 +00:00
|
|
|
#include <sys/systm.h>
|
|
|
|
#include <sys/kernel.h>
|
2012-08-15 15:56:21 +00:00
|
|
|
#include <sys/limits.h>
|
2011-01-21 10:26:26 +00:00
|
|
|
#include <sys/msgbuf.h>
|
2012-08-15 15:56:21 +00:00
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/proc.h>
|
1994-05-24 10:09:53 +00:00
|
|
|
|
2011-03-23 16:38:29 +00:00
|
|
|
#include <vm/vm.h>
|
2004-11-08 18:20:02 +00:00
|
|
|
#include <vm/vm_param.h>
|
2011-03-23 16:38:29 +00:00
|
|
|
#include <vm/pmap.h>
|
2001-10-10 23:06:54 +00:00
|
|
|
|
1994-05-24 10:09:53 +00:00
|
|
|
/*
|
|
|
|
* System parameter formulae.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef HZ
|
2010-06-24 00:27:20 +00:00
|
|
|
# if defined(__mips__) || defined(__arm__)
|
2004-11-06 11:33:43 +00:00
|
|
|
# define HZ 100
|
2010-06-24 00:27:20 +00:00
|
|
|
# else
|
|
|
|
# define HZ 1000
|
2004-11-30 03:23:35 +00:00
|
|
|
# endif
|
2008-10-27 06:25:02 +00:00
|
|
|
# ifndef HZ_VM
|
2009-07-08 01:09:12 +00:00
|
|
|
# define HZ_VM 100
|
2008-10-27 06:25:02 +00:00
|
|
|
# endif
|
|
|
|
#else
|
|
|
|
# ifndef HZ_VM
|
|
|
|
# define HZ_VM HZ
|
|
|
|
# endif
|
2004-03-14 05:49:31 +00:00
|
|
|
#endif
|
2001-07-26 23:04:03 +00:00
|
|
|
#define NPROC (20 + 16 * maxusers)
|
|
|
|
#ifndef NBUF
|
|
|
|
#define NBUF 0
|
|
|
|
#endif
|
1999-04-09 16:28:11 +00:00
|
|
|
#ifndef MAXFILES
|
2001-07-26 23:04:03 +00:00
|
|
|
#define MAXFILES (maxproc * 2)
|
1999-04-09 16:28:11 +00:00
|
|
|
#endif
|
1998-11-05 14:28:26 +00:00
|
|
|
|
2008-12-18 15:34:38 +00:00
|
|
|
static int sysctl_kern_vm_guest(SYSCTL_HANDLER_ARGS);
|
|
|
|
|
2001-07-26 23:04:03 +00:00
|
|
|
int hz;
|
|
|
|
int tick;
|
|
|
|
int maxusers; /* base tunable */
|
|
|
|
int maxproc; /* maximum # of processes */
|
|
|
|
int maxprocperuid; /* max # of procs per user */
|
|
|
|
int maxfiles; /* sys. wide open files limit */
|
|
|
|
int maxfilesperproc; /* per-proc open files limit */
|
2011-01-21 10:26:26 +00:00
|
|
|
int msgbufsize; /* size of kernel message buffer */
|
2001-07-26 23:04:03 +00:00
|
|
|
int ncallout; /* maximum # of timer events */
|
|
|
|
int nbuf;
|
2010-01-12 07:49:34 +00:00
|
|
|
int ngroups_max; /* max # groups per process */
|
2001-07-26 23:04:03 +00:00
|
|
|
int nswbuf;
|
2012-08-15 15:56:21 +00:00
|
|
|
pid_t pid_max = PID_MAX;
|
Adjust some variables (mostly related to the buffer cache) that hold
address space sizes to be longs instead of ints. Specifically, the follow
values are now longs: runningbufspace, bufspace, maxbufspace,
bufmallocspace, maxbufmallocspace, lobufspace, hibufspace, lorunningspace,
hirunningspace, maxswzone, maxbcache, and maxpipekva. Previously, a
relatively small number (~ 44000) of buffers set in kern.nbuf would result
in integer overflows resulting either in hangs or bogus values of
hidirtybuffers and lodirtybuffers. Now one has to overflow a long to see
such problems. There was a check for a nbuf setting that would cause
overflows in the auto-tuning of nbuf. I've changed it to always check and
cap nbuf but warn if a user-supplied tunable would cause overflow.
Note that this changes the ABI of several sysctls that are used by things
like top(1), etc., so any MFC would probably require a some gross shims
to allow for that.
MFC after: 1 month
2009-03-09 19:35:20 +00:00
|
|
|
long maxswzone; /* max swmeta KVA storage */
|
|
|
|
long maxbcache; /* max buffer cache KVA storage */
|
2009-03-10 21:28:43 +00:00
|
|
|
long maxpipekva; /* Limit on pipe KVA */
|
2008-12-18 15:34:38 +00:00
|
|
|
int vm_guest; /* Running as virtual machine guest? */
|
2004-11-08 18:20:02 +00:00
|
|
|
u_long maxtsiz; /* max text size */
|
|
|
|
u_long dfldsiz; /* initial data size limit */
|
|
|
|
u_long maxdsiz; /* max data size */
|
|
|
|
u_long dflssiz; /* initial stack size limit */
|
|
|
|
u_long maxssiz; /* max stack size */
|
|
|
|
u_long sgrowsiz; /* amount to grow stack */
|
1994-05-24 10:09:53 +00:00
|
|
|
|
2009-03-23 20:18:06 +00:00
|
|
|
SYSCTL_INT(_kern, OID_AUTO, hz, CTLFLAG_RDTUN, &hz, 0,
|
|
|
|
"Number of clock ticks per second");
|
2009-03-12 17:21:58 +00:00
|
|
|
SYSCTL_INT(_kern, OID_AUTO, ncallout, CTLFLAG_RDTUN, &ncallout, 0,
|
|
|
|
"Number of pre-allocated timer events");
|
|
|
|
SYSCTL_INT(_kern, OID_AUTO, nbuf, CTLFLAG_RDTUN, &nbuf, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Number of buffers in the buffer cache");
|
2009-03-12 17:21:58 +00:00
|
|
|
SYSCTL_INT(_kern, OID_AUTO, nswbuf, CTLFLAG_RDTUN, &nswbuf, 0,
|
|
|
|
"Number of swap buffers");
|
2011-01-21 10:26:26 +00:00
|
|
|
SYSCTL_INT(_kern, OID_AUTO, msgbufsize, CTLFLAG_RDTUN, &msgbufsize, 0,
|
|
|
|
"Size of the kernel message buffer");
|
2009-03-12 17:23:02 +00:00
|
|
|
SYSCTL_LONG(_kern, OID_AUTO, maxswzone, CTLFLAG_RDTUN, &maxswzone, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Maximum memory for swap metadata");
|
2009-03-12 17:23:02 +00:00
|
|
|
SYSCTL_LONG(_kern, OID_AUTO, maxbcache, CTLFLAG_RDTUN, &maxbcache, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Maximum value of vfs.maxbufspace");
|
2012-09-03 09:26:56 +00:00
|
|
|
SYSCTL_ULONG(_kern, OID_AUTO, maxtsiz, CTLFLAG_RW | CTLFLAG_TUN, &maxtsiz, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Maximum text size");
|
2012-09-03 09:26:56 +00:00
|
|
|
SYSCTL_ULONG(_kern, OID_AUTO, dfldsiz, CTLFLAG_RW | CTLFLAG_TUN, &dfldsiz, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Initial data size limit");
|
2012-09-03 09:26:56 +00:00
|
|
|
SYSCTL_ULONG(_kern, OID_AUTO, maxdsiz, CTLFLAG_RW | CTLFLAG_TUN, &maxdsiz, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Maximum data size");
|
2012-09-03 09:26:56 +00:00
|
|
|
SYSCTL_ULONG(_kern, OID_AUTO, dflssiz, CTLFLAG_RW | CTLFLAG_TUN, &dflssiz, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Initial stack size limit");
|
2012-09-03 09:26:56 +00:00
|
|
|
SYSCTL_ULONG(_kern, OID_AUTO, maxssiz, CTLFLAG_RW | CTLFLAG_TUN, &maxssiz, 0,
|
2009-03-23 20:18:06 +00:00
|
|
|
"Maximum stack size");
|
2012-09-03 09:26:56 +00:00
|
|
|
SYSCTL_ULONG(_kern, OID_AUTO, sgrowsiz, CTLFLAG_RW | CTLFLAG_TUN, &sgrowsiz, 0,
|
|
|
|
"Amount to grow stack on a stack fault");
|
2008-12-18 15:34:38 +00:00
|
|
|
SYSCTL_PROC(_kern, OID_AUTO, vm_guest, CTLFLAG_RD | CTLTYPE_STRING,
|
|
|
|
NULL, 0, sysctl_kern_vm_guest, "A",
|
2010-03-02 23:57:42 +00:00
|
|
|
"Virtual machine guest detected? (none|generic|xen)");
|
2007-10-16 10:40:53 +00:00
|
|
|
|
1994-05-24 10:09:53 +00:00
|
|
|
/*
|
|
|
|
* These have to be allocated somewhere; allocating
|
|
|
|
* them here forces loader errors if this file is omitted
|
|
|
|
* (if they've been externed everywhere else; hah!).
|
|
|
|
*/
|
1995-07-29 11:44:31 +00:00
|
|
|
struct buf *swbuf;
|
2000-10-12 22:37:28 +00:00
|
|
|
|
2010-02-27 18:00:57 +00:00
|
|
|
/*
|
|
|
|
* The elements of this array are ordered based upon the values of the
|
|
|
|
* corresponding enum VM_GUEST members.
|
|
|
|
*/
|
2008-12-27 17:19:16 +00:00
|
|
|
static const char *const vm_guest_sysctl_names[] = {
|
|
|
|
"none",
|
|
|
|
"generic",
|
|
|
|
"xen",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
#ifndef XEN
|
2008-12-08 18:39:59 +00:00
|
|
|
static const char *const vm_bnames[] = {
|
|
|
|
"QEMU", /* QEMU */
|
|
|
|
"Plex86", /* Plex86 */
|
|
|
|
"Bochs", /* Bochs */
|
2010-08-06 15:04:40 +00:00
|
|
|
"Xen", /* Xen */
|
2013-01-05 19:18:50 +00:00
|
|
|
"BHYVE", /* bhyve */
|
2013-01-15 14:05:59 +00:00
|
|
|
"Seabios", /* KVM */
|
2008-12-08 18:39:59 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2008-10-27 08:09:05 +00:00
|
|
|
static const char *const vm_pnames[] = {
|
2008-10-27 06:25:02 +00:00
|
|
|
"VMware Virtual Platform", /* VMWare VM */
|
|
|
|
"Virtual Machine", /* Microsoft VirtualPC */
|
|
|
|
"VirtualBox", /* Sun xVM VirtualBox */
|
|
|
|
"Parallels Virtual Platform", /* Parallels VM */
|
2013-01-15 14:05:59 +00:00
|
|
|
"KVM", /* KVM */
|
2008-10-27 06:25:02 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2008-12-18 15:34:38 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Detect known Virtual Machine hosts by inspecting the emulated BIOS.
|
|
|
|
*/
|
Introduce a sysctl kern.vm_guest that reflects what the kernel knows about
it running under a virtual environment. This also introduces a globally
accessible variable vm_guest that can be used where appropriate in the
kernel to inspect this environment.
To make it easier for the long run, an enum VM_GUEST is also introduced,
which could possibly be factored out in a header somewhere (but the
question is where - vm/vm_param.h? sys/param.h?) so it eventually becomes
a part of the standard KPI. In any case, it's a start.
The purpose of all this isn't to absolutely detect that the OS is running
under a virtual environment (cf. "redpill") but to allow the parts of the
kernel and the userland that care about this particular aspect and can do
something useful depending on it to have a standardised interface. Reducing
kern.hz is one example but there are other things that could be done like
avoiding context switches, not using CPU instructions that are known to be
slow in emulation, possibly different strategies in VM (memory) allocation,
CPU scheduling, etc.
It isn't clear if the JAILS/VIMAGE functionality should also be exposed
by this particular mechanism (probably not since they're not "full"
virtual hardware environments). Sometime in the future another sysctl and
a variable could be introduced to reflect if the kernel supports any kind
of virtual hosting (e.g. VMWare VMI, Xen dom0).
Reviewed by: silence from src-commiters@, virtualization@, kmacy@
Approved by: gnn (mentor)
Security: Obscurity doesn't help.
2008-12-17 19:57:12 +00:00
|
|
|
static enum VM_GUEST
|
2008-10-27 06:25:02 +00:00
|
|
|
detect_virtual(void)
|
|
|
|
{
|
|
|
|
char *sysenv;
|
|
|
|
int i;
|
|
|
|
|
2008-12-08 18:39:59 +00:00
|
|
|
sysenv = getenv("smbios.bios.vendor");
|
|
|
|
if (sysenv != NULL) {
|
|
|
|
for (i = 0; vm_bnames[i] != NULL; i++)
|
|
|
|
if (strcmp(sysenv, vm_bnames[i]) == 0) {
|
|
|
|
freeenv(sysenv);
|
Introduce a sysctl kern.vm_guest that reflects what the kernel knows about
it running under a virtual environment. This also introduces a globally
accessible variable vm_guest that can be used where appropriate in the
kernel to inspect this environment.
To make it easier for the long run, an enum VM_GUEST is also introduced,
which could possibly be factored out in a header somewhere (but the
question is where - vm/vm_param.h? sys/param.h?) so it eventually becomes
a part of the standard KPI. In any case, it's a start.
The purpose of all this isn't to absolutely detect that the OS is running
under a virtual environment (cf. "redpill") but to allow the parts of the
kernel and the userland that care about this particular aspect and can do
something useful depending on it to have a standardised interface. Reducing
kern.hz is one example but there are other things that could be done like
avoiding context switches, not using CPU instructions that are known to be
slow in emulation, possibly different strategies in VM (memory) allocation,
CPU scheduling, etc.
It isn't clear if the JAILS/VIMAGE functionality should also be exposed
by this particular mechanism (probably not since they're not "full"
virtual hardware environments). Sometime in the future another sysctl and
a variable could be introduced to reflect if the kernel supports any kind
of virtual hosting (e.g. VMWare VMI, Xen dom0).
Reviewed by: silence from src-commiters@, virtualization@, kmacy@
Approved by: gnn (mentor)
Security: Obscurity doesn't help.
2008-12-17 19:57:12 +00:00
|
|
|
return (VM_GUEST_VM);
|
2008-12-08 18:39:59 +00:00
|
|
|
}
|
|
|
|
freeenv(sysenv);
|
|
|
|
}
|
2008-10-27 06:25:02 +00:00
|
|
|
sysenv = getenv("smbios.system.product");
|
|
|
|
if (sysenv != NULL) {
|
2008-12-08 18:39:59 +00:00
|
|
|
for (i = 0; vm_pnames[i] != NULL; i++)
|
|
|
|
if (strcmp(sysenv, vm_pnames[i]) == 0) {
|
|
|
|
freeenv(sysenv);
|
Introduce a sysctl kern.vm_guest that reflects what the kernel knows about
it running under a virtual environment. This also introduces a globally
accessible variable vm_guest that can be used where appropriate in the
kernel to inspect this environment.
To make it easier for the long run, an enum VM_GUEST is also introduced,
which could possibly be factored out in a header somewhere (but the
question is where - vm/vm_param.h? sys/param.h?) so it eventually becomes
a part of the standard KPI. In any case, it's a start.
The purpose of all this isn't to absolutely detect that the OS is running
under a virtual environment (cf. "redpill") but to allow the parts of the
kernel and the userland that care about this particular aspect and can do
something useful depending on it to have a standardised interface. Reducing
kern.hz is one example but there are other things that could be done like
avoiding context switches, not using CPU instructions that are known to be
slow in emulation, possibly different strategies in VM (memory) allocation,
CPU scheduling, etc.
It isn't clear if the JAILS/VIMAGE functionality should also be exposed
by this particular mechanism (probably not since they're not "full"
virtual hardware environments). Sometime in the future another sysctl and
a variable could be introduced to reflect if the kernel supports any kind
of virtual hosting (e.g. VMWare VMI, Xen dom0).
Reviewed by: silence from src-commiters@, virtualization@, kmacy@
Approved by: gnn (mentor)
Security: Obscurity doesn't help.
2008-12-17 19:57:12 +00:00
|
|
|
return (VM_GUEST_VM);
|
2008-12-08 18:39:59 +00:00
|
|
|
}
|
|
|
|
freeenv(sysenv);
|
2008-10-27 06:25:02 +00:00
|
|
|
}
|
Introduce a sysctl kern.vm_guest that reflects what the kernel knows about
it running under a virtual environment. This also introduces a globally
accessible variable vm_guest that can be used where appropriate in the
kernel to inspect this environment.
To make it easier for the long run, an enum VM_GUEST is also introduced,
which could possibly be factored out in a header somewhere (but the
question is where - vm/vm_param.h? sys/param.h?) so it eventually becomes
a part of the standard KPI. In any case, it's a start.
The purpose of all this isn't to absolutely detect that the OS is running
under a virtual environment (cf. "redpill") but to allow the parts of the
kernel and the userland that care about this particular aspect and can do
something useful depending on it to have a standardised interface. Reducing
kern.hz is one example but there are other things that could be done like
avoiding context switches, not using CPU instructions that are known to be
slow in emulation, possibly different strategies in VM (memory) allocation,
CPU scheduling, etc.
It isn't clear if the JAILS/VIMAGE functionality should also be exposed
by this particular mechanism (probably not since they're not "full"
virtual hardware environments). Sometime in the future another sysctl and
a variable could be introduced to reflect if the kernel supports any kind
of virtual hosting (e.g. VMWare VMI, Xen dom0).
Reviewed by: silence from src-commiters@, virtualization@, kmacy@
Approved by: gnn (mentor)
Security: Obscurity doesn't help.
2008-12-17 19:57:12 +00:00
|
|
|
return (VM_GUEST_NO);
|
2008-10-27 06:25:02 +00:00
|
|
|
}
|
2008-12-27 17:19:16 +00:00
|
|
|
#endif
|
2008-10-27 06:25:02 +00:00
|
|
|
|
2001-07-26 23:04:03 +00:00
|
|
|
/*
|
2001-12-09 01:57:09 +00:00
|
|
|
* Boot time overrides that are not scaled against main memory
|
2001-07-26 23:04:03 +00:00
|
|
|
*/
|
|
|
|
void
|
2001-12-09 01:57:09 +00:00
|
|
|
init_param1(void)
|
2001-07-26 23:04:03 +00:00
|
|
|
{
|
Introduce a sysctl kern.vm_guest that reflects what the kernel knows about
it running under a virtual environment. This also introduces a globally
accessible variable vm_guest that can be used where appropriate in the
kernel to inspect this environment.
To make it easier for the long run, an enum VM_GUEST is also introduced,
which could possibly be factored out in a header somewhere (but the
question is where - vm/vm_param.h? sys/param.h?) so it eventually becomes
a part of the standard KPI. In any case, it's a start.
The purpose of all this isn't to absolutely detect that the OS is running
under a virtual environment (cf. "redpill") but to allow the parts of the
kernel and the userland that care about this particular aspect and can do
something useful depending on it to have a standardised interface. Reducing
kern.hz is one example but there are other things that could be done like
avoiding context switches, not using CPU instructions that are known to be
slow in emulation, possibly different strategies in VM (memory) allocation,
CPU scheduling, etc.
It isn't clear if the JAILS/VIMAGE functionality should also be exposed
by this particular mechanism (probably not since they're not "full"
virtual hardware environments). Sometime in the future another sysctl and
a variable could be introduced to reflect if the kernel supports any kind
of virtual hosting (e.g. VMWare VMI, Xen dom0).
Reviewed by: silence from src-commiters@, virtualization@, kmacy@
Approved by: gnn (mentor)
Security: Obscurity doesn't help.
2008-12-17 19:57:12 +00:00
|
|
|
#ifndef XEN
|
|
|
|
vm_guest = detect_virtual();
|
|
|
|
#else
|
|
|
|
vm_guest = VM_GUEST_XEN;
|
|
|
|
#endif
|
2008-10-27 06:25:02 +00:00
|
|
|
hz = -1;
|
2001-07-26 23:04:03 +00:00
|
|
|
TUNABLE_INT_FETCH("kern.hz", &hz);
|
2008-12-08 18:39:59 +00:00
|
|
|
if (hz == -1)
|
Introduce a sysctl kern.vm_guest that reflects what the kernel knows about
it running under a virtual environment. This also introduces a globally
accessible variable vm_guest that can be used where appropriate in the
kernel to inspect this environment.
To make it easier for the long run, an enum VM_GUEST is also introduced,
which could possibly be factored out in a header somewhere (but the
question is where - vm/vm_param.h? sys/param.h?) so it eventually becomes
a part of the standard KPI. In any case, it's a start.
The purpose of all this isn't to absolutely detect that the OS is running
under a virtual environment (cf. "redpill") but to allow the parts of the
kernel and the userland that care about this particular aspect and can do
something useful depending on it to have a standardised interface. Reducing
kern.hz is one example but there are other things that could be done like
avoiding context switches, not using CPU instructions that are known to be
slow in emulation, possibly different strategies in VM (memory) allocation,
CPU scheduling, etc.
It isn't clear if the JAILS/VIMAGE functionality should also be exposed
by this particular mechanism (probably not since they're not "full"
virtual hardware environments). Sometime in the future another sysctl and
a variable could be introduced to reflect if the kernel supports any kind
of virtual hosting (e.g. VMWare VMI, Xen dom0).
Reviewed by: silence from src-commiters@, virtualization@, kmacy@
Approved by: gnn (mentor)
Security: Obscurity doesn't help.
2008-12-17 19:57:12 +00:00
|
|
|
hz = vm_guest > VM_GUEST_NO ? HZ_VM : HZ;
|
2001-07-26 23:04:03 +00:00
|
|
|
tick = 1000000 / hz;
|
|
|
|
|
2001-08-20 16:29:13 +00:00
|
|
|
#ifdef VM_SWZONE_SIZE_MAX
|
2001-08-20 00:41:12 +00:00
|
|
|
maxswzone = VM_SWZONE_SIZE_MAX;
|
2001-08-20 16:29:13 +00:00
|
|
|
#endif
|
Adjust some variables (mostly related to the buffer cache) that hold
address space sizes to be longs instead of ints. Specifically, the follow
values are now longs: runningbufspace, bufspace, maxbufspace,
bufmallocspace, maxbufmallocspace, lobufspace, hibufspace, lorunningspace,
hirunningspace, maxswzone, maxbcache, and maxpipekva. Previously, a
relatively small number (~ 44000) of buffers set in kern.nbuf would result
in integer overflows resulting either in hangs or bogus values of
hidirtybuffers and lodirtybuffers. Now one has to overflow a long to see
such problems. There was a check for a nbuf setting that would cause
overflows in the auto-tuning of nbuf. I've changed it to always check and
cap nbuf but warn if a user-supplied tunable would cause overflow.
Note that this changes the ABI of several sysctls that are used by things
like top(1), etc., so any MFC would probably require a some gross shims
to allow for that.
MFC after: 1 month
2009-03-09 19:35:20 +00:00
|
|
|
TUNABLE_LONG_FETCH("kern.maxswzone", &maxswzone);
|
2001-08-20 16:29:13 +00:00
|
|
|
#ifdef VM_BCACHE_SIZE_MAX
|
2001-08-20 00:41:12 +00:00
|
|
|
maxbcache = VM_BCACHE_SIZE_MAX;
|
2001-08-20 16:29:13 +00:00
|
|
|
#endif
|
Adjust some variables (mostly related to the buffer cache) that hold
address space sizes to be longs instead of ints. Specifically, the follow
values are now longs: runningbufspace, bufspace, maxbufspace,
bufmallocspace, maxbufmallocspace, lobufspace, hibufspace, lorunningspace,
hirunningspace, maxswzone, maxbcache, and maxpipekva. Previously, a
relatively small number (~ 44000) of buffers set in kern.nbuf would result
in integer overflows resulting either in hangs or bogus values of
hidirtybuffers and lodirtybuffers. Now one has to overflow a long to see
such problems. There was a check for a nbuf setting that would cause
overflows in the auto-tuning of nbuf. I've changed it to always check and
cap nbuf but warn if a user-supplied tunable would cause overflow.
Note that this changes the ABI of several sysctls that are used by things
like top(1), etc., so any MFC would probably require a some gross shims
to allow for that.
MFC after: 1 month
2009-03-09 19:35:20 +00:00
|
|
|
TUNABLE_LONG_FETCH("kern.maxbcache", &maxbcache);
|
2011-01-21 10:26:26 +00:00
|
|
|
msgbufsize = MSGBUF_SIZE;
|
|
|
|
TUNABLE_INT_FETCH("kern.msgbufsize", &msgbufsize);
|
2001-10-10 23:06:54 +00:00
|
|
|
|
|
|
|
maxtsiz = MAXTSIZ;
|
2004-11-08 18:20:02 +00:00
|
|
|
TUNABLE_ULONG_FETCH("kern.maxtsiz", &maxtsiz);
|
2001-10-10 23:06:54 +00:00
|
|
|
dfldsiz = DFLDSIZ;
|
2004-11-08 18:20:02 +00:00
|
|
|
TUNABLE_ULONG_FETCH("kern.dfldsiz", &dfldsiz);
|
2001-10-10 23:06:54 +00:00
|
|
|
maxdsiz = MAXDSIZ;
|
2004-11-08 18:20:02 +00:00
|
|
|
TUNABLE_ULONG_FETCH("kern.maxdsiz", &maxdsiz);
|
2001-10-10 23:06:54 +00:00
|
|
|
dflssiz = DFLSSIZ;
|
2004-11-08 18:20:02 +00:00
|
|
|
TUNABLE_ULONG_FETCH("kern.dflssiz", &dflssiz);
|
2001-10-10 23:06:54 +00:00
|
|
|
maxssiz = MAXSSIZ;
|
2004-11-08 18:20:02 +00:00
|
|
|
TUNABLE_ULONG_FETCH("kern.maxssiz", &maxssiz);
|
2001-10-10 23:06:54 +00:00
|
|
|
sgrowsiz = SGROWSIZ;
|
2004-11-08 18:20:02 +00:00
|
|
|
TUNABLE_ULONG_FETCH("kern.sgrowsiz", &sgrowsiz);
|
2010-01-12 07:49:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Let the administrator set {NGROUPS_MAX}, but disallow values
|
|
|
|
* less than NGROUPS_MAX which would violate POSIX.1-2008 or
|
|
|
|
* greater than INT_MAX-1 which would result in overflow.
|
|
|
|
*/
|
|
|
|
ngroups_max = NGROUPS_MAX;
|
|
|
|
TUNABLE_INT_FETCH("kern.ngroups", &ngroups_max);
|
|
|
|
if (ngroups_max < NGROUPS_MAX)
|
|
|
|
ngroups_max = NGROUPS_MAX;
|
2012-08-15 15:56:21 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only allow to lower the maximal pid.
|
2012-08-16 13:04:21 +00:00
|
|
|
* Prevent setting up a non-bootable system if pid_max is too low.
|
2012-08-15 15:56:21 +00:00
|
|
|
*/
|
|
|
|
TUNABLE_INT_FETCH("kern.pid_max", &pid_max);
|
|
|
|
if (pid_max > PID_MAX)
|
|
|
|
pid_max = PID_MAX;
|
2012-08-16 13:04:21 +00:00
|
|
|
else if (pid_max < 300)
|
|
|
|
pid_max = 300;
|
2001-07-26 23:04:03 +00:00
|
|
|
}
|
2001-12-09 01:57:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Boot time overrides that are scaled against main memory
|
|
|
|
*/
|
|
|
|
void
|
2002-08-30 04:04:37 +00:00
|
|
|
init_param2(long physpages)
|
2001-12-09 01:57:09 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
/* Base parameters */
|
2002-02-06 01:19:19 +00:00
|
|
|
maxusers = MAXUSERS;
|
|
|
|
TUNABLE_INT_FETCH("kern.maxusers", &maxusers);
|
|
|
|
if (maxusers == 0) {
|
2002-01-25 01:54:16 +00:00
|
|
|
maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE);
|
2001-12-09 01:57:09 +00:00
|
|
|
if (maxusers < 32)
|
|
|
|
maxusers = 32;
|
2012-11-10 02:08:40 +00:00
|
|
|
#ifdef VM_MAX_AUTOTUNE_MAXUSERS
|
|
|
|
if (maxusers > VM_MAX_AUTOTUNE_MAXUSERS)
|
|
|
|
maxusers = VM_MAX_AUTOTUNE_MAXUSERS;
|
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* Scales down the function in which maxusers grows once
|
|
|
|
* we hit 384.
|
|
|
|
*/
|
|
|
|
if (maxusers > 384)
|
|
|
|
maxusers = 384 + ((maxusers - 384) / 8);
|
|
|
|
}
|
2001-12-09 01:57:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The following can be overridden after boot via sysctl. Note:
|
|
|
|
* unless overriden, these macros are ultimately based on maxusers.
|
2002-03-07 04:50:36 +00:00
|
|
|
* Limit maxproc so that kmap entries cannot be exhausted by
|
|
|
|
* processes.
|
|
|
|
*/
|
Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.
The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.
At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.
Tidy up ordering in init_param2() and check up on some users of
those values calculated here.
Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.
Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.
The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.
NB: Every cluster also has an mbuf associated with it.
Two examples on the revised mbuf sizing limits:
1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters
16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters
These defaults should be sufficient for even the most demanding
network loads.
MFC after: 1 month
2012-11-27 21:19:58 +00:00
|
|
|
maxproc = NPROC;
|
|
|
|
TUNABLE_INT_FETCH("kern.maxproc", &maxproc);
|
2002-03-07 04:50:36 +00:00
|
|
|
if (maxproc > (physpages / 12))
|
|
|
|
maxproc = physpages / 12;
|
2001-12-13 20:00:45 +00:00
|
|
|
maxprocperuid = (maxproc * 9) / 10;
|
Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.
The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.
At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.
Tidy up ordering in init_param2() and check up on some users of
those values calculated here.
Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.
Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.
The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.
NB: Every cluster also has an mbuf associated with it.
Two examples on the revised mbuf sizing limits:
1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters
16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters
These defaults should be sufficient for even the most demanding
network loads.
MFC after: 1 month
2012-11-27 21:19:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The default limit for maxfiles is 1/12 of the number of
|
|
|
|
* physical page but not less than 16 times maxusers.
|
|
|
|
* At most it can be 1/6 the number of physical pages.
|
|
|
|
*/
|
|
|
|
maxfiles = imax(MAXFILES, physpages / 8);
|
|
|
|
TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
|
|
|
|
if (maxfiles > (physpages / 4))
|
|
|
|
maxfiles = physpages / 4;
|
|
|
|
maxfilesperproc = (maxfiles / 10) * 9;
|
2003-07-11 00:01:03 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Cannot be changed after boot.
|
|
|
|
*/
|
|
|
|
nbuf = NBUF;
|
|
|
|
TUNABLE_INT_FETCH("kern.nbuf", &nbuf);
|
|
|
|
|
Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.
The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.
At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.
Tidy up ordering in init_param2() and check up on some users of
those values calculated here.
Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.
Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.
The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.
NB: Every cluster also has an mbuf associated with it.
Two examples on the revised mbuf sizing limits:
1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters
16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters
These defaults should be sufficient for even the most demanding
network loads.
MFC after: 1 month
2012-11-27 21:19:58 +00:00
|
|
|
/*
|
|
|
|
* XXX: Does the callout wheel have to be so big?
|
2013-01-15 19:26:17 +00:00
|
|
|
*
|
|
|
|
* Clip callout to result of previous function of maxusers maximum
|
|
|
|
* 384. This is still huge, but acceptable.
|
Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.
The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.
At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.
Tidy up ordering in init_param2() and check up on some users of
those values calculated here.
Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.
Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.
The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.
NB: Every cluster also has an mbuf associated with it.
Two examples on the revised mbuf sizing limits:
1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters
16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters
These defaults should be sufficient for even the most demanding
network loads.
MFC after: 1 month
2012-11-27 21:19:58 +00:00
|
|
|
*/
|
2013-01-15 19:26:17 +00:00
|
|
|
ncallout = imin(16 + maxproc + maxfiles, 18508);
|
2003-07-11 00:01:03 +00:00
|
|
|
TUNABLE_INT_FETCH("kern.ncallout", &ncallout);
|
2004-03-30 08:00:11 +00:00
|
|
|
|
2003-07-08 04:02:31 +00:00
|
|
|
/*
|
2011-03-23 16:38:29 +00:00
|
|
|
* The default for maxpipekva is min(1/64 of the kernel address space,
|
|
|
|
* max(1/64 of main memory, 512KB)). See sys_pipe.c for more details.
|
2003-07-08 04:02:31 +00:00
|
|
|
*/
|
2011-03-23 16:38:29 +00:00
|
|
|
maxpipekva = (physpages / 64) * PAGE_SIZE;
|
Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.
The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.
At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.
Tidy up ordering in init_param2() and check up on some users of
those values calculated here.
Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.
Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.
The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.
NB: Every cluster also has an mbuf associated with it.
Two examples on the revised mbuf sizing limits:
1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters
16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters
These defaults should be sufficient for even the most demanding
network loads.
MFC after: 1 month
2012-11-27 21:19:58 +00:00
|
|
|
TUNABLE_LONG_FETCH("kern.ipc.maxpipekva", &maxpipekva);
|
2003-07-08 04:02:31 +00:00
|
|
|
if (maxpipekva < 512 * 1024)
|
|
|
|
maxpipekva = 512 * 1024;
|
2011-03-23 16:38:29 +00:00
|
|
|
if (maxpipekva > (VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS) / 64)
|
|
|
|
maxpipekva = (VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS) /
|
|
|
|
64;
|
2001-12-09 01:57:09 +00:00
|
|
|
}
|
2008-12-18 15:34:38 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Sysctl stringiying handler for kern.vm_guest.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
sysctl_kern_vm_guest(SYSCTL_HANDLER_ARGS)
|
|
|
|
{
|
|
|
|
return (SYSCTL_OUT(req, vm_guest_sysctl_names[vm_guest],
|
|
|
|
strlen(vm_guest_sysctl_names[vm_guest])));
|
|
|
|
}
|