Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
/*-
|
2001-09-03 22:27:23 +00:00
|
|
|
* Copyright (c) 1990 The Regents of the University of California.
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
* All rights reserved.
|
2001-09-03 22:27:23 +00:00
|
|
|
* Copyright (c) 1994 John S. Dyson
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This code is derived from software contributed to Berkeley by
|
|
|
|
* William Jolitz.
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
*
|
|
|
|
* 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.
|
2017-02-28 23:42:47 +00:00
|
|
|
* 3. Neither the name of the University nor the names of its contributors
|
2001-09-03 22:27:23 +00:00
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
* without specific prior written permission.
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
*
|
2001-09-03 22:27:23 +00:00
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
2001-09-03 22:27:23 +00:00
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
* 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.
|
|
|
|
*
|
2001-09-03 22:27:23 +00:00
|
|
|
* from: @(#)vmparam.h 5.9 (Berkeley) 5/12/91
|
|
|
|
* from: FreeBSD: src/sys/i386/include/vmparam.h,v 1.33 2000/03/30
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
* $FreeBSD$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _MACHINE_VMPARAM_H_
|
|
|
|
#define _MACHINE_VMPARAM_H_
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Virtual memory related constants, all in bytes
|
|
|
|
*/
|
|
|
|
#ifndef MAXTSIZ
|
|
|
|
#define MAXTSIZ (1*1024*1024*1024) /* max text size */
|
|
|
|
#endif
|
|
|
|
#ifndef DFLDSIZ
|
|
|
|
#define DFLDSIZ (128*1024*1024) /* initial data size limit */
|
|
|
|
#endif
|
|
|
|
#ifndef MAXDSIZ
|
|
|
|
#define MAXDSIZ (1*1024*1024*1024) /* max data size */
|
|
|
|
#endif
|
|
|
|
#ifndef DFLSSIZ
|
|
|
|
#define DFLSSIZ (128*1024*1024) /* initial stack size limit */
|
|
|
|
#endif
|
|
|
|
#ifndef MAXSSIZ
|
|
|
|
#define MAXSSIZ (1*1024*1024*1024) /* max stack size */
|
|
|
|
#endif
|
|
|
|
#ifndef SGROWSIZ
|
|
|
|
#define SGROWSIZ (128*1024) /* amount to grow stack */
|
|
|
|
#endif
|
|
|
|
|
2007-05-05 19:50:28 +00:00
|
|
|
/*
|
|
|
|
* The physical address space is sparsely populated.
|
|
|
|
*/
|
|
|
|
#define VM_PHYSSEG_SPARSE
|
|
|
|
|
2007-06-04 02:32:07 +00:00
|
|
|
/*
|
|
|
|
* The number of PHYSSEG entries must be one greater than the number
|
|
|
|
* of phys_avail entries because the phys_avail entry that spans the
|
|
|
|
* largest physical address that is accessible by ISA DMA is split
|
2011-06-21 20:50:55 +00:00
|
|
|
* into two PHYSSEG entries.
|
2007-06-04 02:32:07 +00:00
|
|
|
*/
|
|
|
|
#define VM_PHYSSEG_MAX 64
|
|
|
|
|
|
|
|
/*
|
2015-06-08 04:59:32 +00:00
|
|
|
* Create two free page pools: VM_FREEPOOL_DEFAULT is the default pool
|
2007-06-04 02:32:07 +00:00
|
|
|
* from which physical pages are allocated and VM_FREEPOOL_DIRECT is
|
|
|
|
* the pool from which physical pages for small UMA objects are
|
|
|
|
* allocated.
|
|
|
|
*/
|
2015-06-08 04:59:32 +00:00
|
|
|
#define VM_NFREEPOOL 2
|
2007-06-04 02:32:07 +00:00
|
|
|
#define VM_FREEPOOL_DEFAULT 0
|
|
|
|
#define VM_FREEPOOL_DIRECT 1
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create two free page lists: VM_FREELIST_DEFAULT is for physical
|
|
|
|
* pages that are above the largest physical address that is
|
|
|
|
* accessible by ISA DMA and VM_FREELIST_ISADMA is for physical pages
|
|
|
|
* that are below that address.
|
|
|
|
*/
|
|
|
|
#define VM_NFREELIST 2
|
|
|
|
#define VM_FREELIST_DEFAULT 0
|
|
|
|
#define VM_FREELIST_ISADMA 1
|
|
|
|
|
|
|
|
/*
|
|
|
|
* An allocation size of 16MB is supported in order to optimize the
|
|
|
|
* use of the direct map by UMA. Specifically, a cache line contains
|
|
|
|
* at most four TTEs, collectively mapping 16MB of physical memory.
|
|
|
|
* By reducing the number of distinct 16MB "pages" that are used by UMA,
|
|
|
|
* the physical memory allocator reduces the likelihood of both 4MB
|
|
|
|
* page TLB misses and cache misses caused by 4MB page TLB misses.
|
|
|
|
*/
|
|
|
|
#define VM_NFREEORDER 12
|
|
|
|
|
2007-12-27 16:45:39 +00:00
|
|
|
/*
|
2010-11-10 17:57:34 +00:00
|
|
|
* Enable superpage reservations: 1 level.
|
2007-12-27 16:45:39 +00:00
|
|
|
*/
|
|
|
|
#ifndef VM_NRESERVLEVEL
|
2010-11-10 17:57:34 +00:00
|
|
|
#define VM_NRESERVLEVEL 1
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Level 0 reservations consist of 512 pages.
|
|
|
|
*/
|
|
|
|
#ifndef VM_LEVEL_0_ORDER
|
|
|
|
#define VM_LEVEL_0_ORDER 9
|
2007-12-27 16:45:39 +00:00
|
|
|
#endif
|
|
|
|
|
2012-09-07 08:18:06 +00:00
|
|
|
/**
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
* Address space layout.
|
|
|
|
*
|
|
|
|
* UltraSPARC I and II implement a 44 bit virtual address space. The address
|
|
|
|
* space is split into 2 regions at each end of the 64 bit address space, with
|
|
|
|
* an out of range "hole" in the middle. UltraSPARC III implements the full
|
|
|
|
* 64 bit virtual address space, but we don't really have any use for it and
|
|
|
|
* 43 bits of user address space is considered to be "enough", so we ignore it.
|
|
|
|
*
|
|
|
|
* Upper region: 0xffffffffffffffff
|
2011-06-21 20:50:55 +00:00
|
|
|
* 0xfffff80000000000
|
|
|
|
*
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
* Hole: 0xfffff7ffffffffff
|
2011-06-21 20:50:55 +00:00
|
|
|
* 0x0000080000000000
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
*
|
|
|
|
* Lower region: 0x000007ffffffffff
|
2011-06-21 20:50:55 +00:00
|
|
|
* 0x0000000000000000
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
*
|
|
|
|
* In general we ignore the upper region, and use the lower region as mappable
|
|
|
|
* space.
|
|
|
|
*
|
|
|
|
* We define some interesting address constants:
|
|
|
|
*
|
2013-02-08 15:52:20 +00:00
|
|
|
* VM_MIN_ADDRESS and VM_MAX_ADDRESS define the start and end of the entire
|
|
|
|
* 64 bit address space, mostly just for convenience.
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
*
|
|
|
|
* VM_MIN_DIRECT_ADDRESS and VM_MAX_DIRECT_ADDRESS define the start and end
|
|
|
|
* of the direct mapped region. This maps virtual addresses to physical
|
|
|
|
* addresses directly using 4mb tlb entries, with the physical address encoded
|
|
|
|
* in the lower 43 bits of virtual address. These mappings are convenient
|
|
|
|
* because they do not require page tables, and because they never change they
|
|
|
|
* do not require tlb flushes. However, since these mappings are cacheable,
|
|
|
|
* we must ensure that all pages accessed this way are either not double
|
|
|
|
* mapped, or that all other mappings have virtual color equal to physical
|
|
|
|
* color, in order to avoid creating illegal aliases in the data cache.
|
|
|
|
*
|
|
|
|
* VM_MIN_KERNEL_ADDRESS and VM_MAX_KERNEL_ADDRESS define the start and end of
|
|
|
|
* mappable kernel virtual address space. VM_MIN_KERNEL_ADDRESS is basically
|
|
|
|
* arbitrary, a convenient address is chosen which allows both the kernel text
|
|
|
|
* and data and the prom's address space to be mapped with 1 4mb tsb page.
|
|
|
|
* VM_MAX_KERNEL_ADDRESS is variable, computed at startup time based on the
|
|
|
|
* amount of physical memory available. Each 4mb tsb page provides 1g of
|
|
|
|
* virtual address space, with the only practical limit being available
|
|
|
|
* phsyical memory.
|
|
|
|
*
|
|
|
|
* VM_MIN_PROM_ADDRESS and VM_MAX_PROM_ADDRESS define the start and end of the
|
|
|
|
* prom address space. On startup the prom's mappings are duplicated in the
|
|
|
|
* kernel tsb, to allow prom memory to be accessed normally by the kernel.
|
|
|
|
*
|
|
|
|
* VM_MIN_USER_ADDRESS and VM_MAX_USER_ADDRESS define the start and end of the
|
|
|
|
* user address space. There are some hardware errata about using addresses
|
|
|
|
* at the boundary of the va hole, so we allow just under 43 bits of user
|
|
|
|
* address space. Note that the kernel and user address spaces overlap, but
|
|
|
|
* this doesn't matter because they use different tlb contexts, and because
|
|
|
|
* the kernel address space is not mapped into each process' address space.
|
2001-12-29 08:25:43 +00:00
|
|
|
*/
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
#define VM_MIN_ADDRESS (0x0000000000000000UL)
|
|
|
|
#define VM_MAX_ADDRESS (0xffffffffffffffffUL)
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
#define VM_MIN_DIRECT_ADDRESS (0xfffff80000000000UL)
|
|
|
|
#define VM_MAX_DIRECT_ADDRESS (VM_MAX_ADDRESS)
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
#define VM_MIN_KERNEL_ADDRESS (0x00000000c0000000UL)
|
|
|
|
#define VM_MAX_KERNEL_ADDRESS (vm_max_kernel_address)
|
|
|
|
|
|
|
|
#define VM_MIN_PROM_ADDRESS (0x00000000f0000000UL)
|
2008-08-12 20:00:28 +00:00
|
|
|
#define VM_MAX_PROM_ADDRESS (0x00000000ffffffffUL)
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
|
|
|
|
#define VM_MIN_USER_ADDRESS (0x0000000000000000UL)
|
|
|
|
#define VM_MAX_USER_ADDRESS (0x000007fe00000000UL)
|
|
|
|
|
|
|
|
#define VM_MINUSER_ADDRESS (VM_MIN_USER_ADDRESS)
|
|
|
|
#define VM_MAXUSER_ADDRESS (VM_MAX_USER_ADDRESS)
|
|
|
|
|
|
|
|
#define KERNBASE (VM_MIN_KERNEL_ADDRESS)
|
2009-02-10 21:48:42 +00:00
|
|
|
#define PROMBASE (VM_MIN_PROM_ADDRESS)
|
- Change the way the direct mapped region is implemented to be generally
useful for accessing more than 1 page of contiguous physical memory, and
to use 4mb tlb entries instead of 8k. This requires that the system only
use the direct mapped addresses when they have the same virtual colour as
all other mappings of the same page, instead of being able to choose the
colour and cachability of the mapping.
- Adapt the physical page copying and zeroing functions to account for not
being able to choose the colour or cachability of the direct mapped
address. This adds a lot more cases to handle. Basically when a page has
a different colour than its direct mapped address we have a choice between
bypassing the data cache and using physical addresses directly, which
requires a cache flush, or mapping it at the right colour, which requires
a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things
that don't require normal pmap handling, including mapping the vm_page
structures, the message buffer, temporary mappings for crash dumps, and will
provide greater benefit for implementing uma_small_alloc, due to the much
greater tlb coverage.
2002-12-23 23:39:57 +00:00
|
|
|
#define USRSTACK (VM_MAX_USER_ADDRESS)
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
|
|
|
|
/*
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
words, every architecture is now auto-sizing the kmem arena. This revision
changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes
mandatory and the definition of VM_KMEM_SIZE becomes optional.
Replace or eliminate all existing definitions of VM_KMEM_SIZE. With
auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling
for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for
clarity.
Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to
that of setting the tunable vm.kmem_size. Whereas the macros
VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables
vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size
have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by
VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size
was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set
the size of the kmem arena at compile-time without that value being
overridden by auto-sizing.
Update the nearby comments to reflect the kmem submap being replaced by the
kmem arena. Stop duplicating the auto-sizing formula in every machine-
dependent vmparam.h and place it in kmeminit() where auto-sizing takes
place.
Reviewed by: kib (an earlier version)
Sponsored by: EMC / Isilon Storage Division
2013-11-08 16:25:00 +00:00
|
|
|
* How many physical pages per kmem arena virtual page.
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
*/
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
words, every architecture is now auto-sizing the kmem arena. This revision
changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes
mandatory and the definition of VM_KMEM_SIZE becomes optional.
Replace or eliminate all existing definitions of VM_KMEM_SIZE. With
auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling
for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for
clarity.
Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to
that of setting the tunable vm.kmem_size. Whereas the macros
VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables
vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size
have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by
VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size
was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set
the size of the kmem arena at compile-time without that value being
overridden by auto-sizing.
Update the nearby comments to reflect the kmem submap being replaced by the
kmem arena. Stop duplicating the auto-sizing formula in every machine-
dependent vmparam.h and place it in kmeminit() where auto-sizing takes
place.
Reviewed by: kib (an earlier version)
Sponsored by: EMC / Isilon Storage Division
2013-11-08 16:25:00 +00:00
|
|
|
#ifndef VM_KMEM_SIZE_SCALE
|
|
|
|
#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 2)
|
2002-03-09 23:35:50 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
words, every architecture is now auto-sizing the kmem arena. This revision
changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes
mandatory and the definition of VM_KMEM_SIZE becomes optional.
Replace or eliminate all existing definitions of VM_KMEM_SIZE. With
auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling
for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for
clarity.
Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to
that of setting the tunable vm.kmem_size. Whereas the macros
VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables
vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size
have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by
VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size
was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set
the size of the kmem arena at compile-time without that value being
overridden by auto-sizing.
Update the nearby comments to reflect the kmem submap being replaced by the
kmem arena. Stop duplicating the auto-sizing formula in every machine-
dependent vmparam.h and place it in kmeminit() where auto-sizing takes
place.
Reviewed by: kib (an earlier version)
Sponsored by: EMC / Isilon Storage Division
2013-11-08 16:25:00 +00:00
|
|
|
* Optional floor (in bytes) on the size of the kmem arena.
|
2002-03-09 23:35:50 +00:00
|
|
|
*/
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
words, every architecture is now auto-sizing the kmem arena. This revision
changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes
mandatory and the definition of VM_KMEM_SIZE becomes optional.
Replace or eliminate all existing definitions of VM_KMEM_SIZE. With
auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling
for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for
clarity.
Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to
that of setting the tunable vm.kmem_size. Whereas the macros
VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables
vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size
have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by
VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size
was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set
the size of the kmem arena at compile-time without that value being
overridden by auto-sizing.
Update the nearby comments to reflect the kmem submap being replaced by the
kmem arena. Stop duplicating the auto-sizing formula in every machine-
dependent vmparam.h and place it in kmeminit() where auto-sizing takes
place.
Reviewed by: kib (an earlier version)
Sponsored by: EMC / Isilon Storage Division
2013-11-08 16:25:00 +00:00
|
|
|
#ifndef VM_KMEM_SIZE_MIN
|
|
|
|
#define VM_KMEM_SIZE_MIN (16 * 1024 * 1024)
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
#endif
|
|
|
|
|
2010-11-28 19:26:20 +00:00
|
|
|
/*
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
words, every architecture is now auto-sizing the kmem arena. This revision
changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes
mandatory and the definition of VM_KMEM_SIZE becomes optional.
Replace or eliminate all existing definitions of VM_KMEM_SIZE. With
auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling
for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for
clarity.
Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to
that of setting the tunable vm.kmem_size. Whereas the macros
VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables
vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size
have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by
VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size
was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set
the size of the kmem arena at compile-time without that value being
overridden by auto-sizing.
Update the nearby comments to reflect the kmem submap being replaced by the
kmem arena. Stop duplicating the auto-sizing formula in every machine-
dependent vmparam.h and place it in kmeminit() where auto-sizing takes
place.
Reviewed by: kib (an earlier version)
Sponsored by: EMC / Isilon Storage Division
2013-11-08 16:25:00 +00:00
|
|
|
* Optional ceiling (in bytes) on the size of the kmem arena: 60% of the
|
|
|
|
* kernel map.
|
2010-11-28 19:26:20 +00:00
|
|
|
*/
|
|
|
|
#ifndef VM_KMEM_SIZE_MAX
|
2010-12-21 21:32:17 +00:00
|
|
|
#define VM_KMEM_SIZE_MAX ((VM_MAX_KERNEL_ADDRESS - \
|
|
|
|
VM_MIN_KERNEL_ADDRESS + 1) * 3 / 5)
|
2010-11-28 19:26:20 +00:00
|
|
|
#endif
|
|
|
|
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
/*
|
|
|
|
* Initial pagein size of beginning of executable file.
|
|
|
|
*/
|
|
|
|
#ifndef VM_INITIAL_PAGEIN
|
|
|
|
#define VM_INITIAL_PAGEIN 16
|
|
|
|
#endif
|
|
|
|
|
2002-12-27 19:31:26 +00:00
|
|
|
#define UMA_MD_SMALL_ALLOC
|
|
|
|
|
2011-06-21 20:48:14 +00:00
|
|
|
extern u_int tsb_kernel_ldd_phys;
|
2002-08-10 22:14:16 +00:00
|
|
|
extern vm_offset_t vm_max_kernel_address;
|
|
|
|
|
2011-05-13 19:35:01 +00:00
|
|
|
/*
|
|
|
|
* Older sparc64 machines have a virtually indexed L1 data cache of 16KB.
|
|
|
|
* Consequently, mapping the same physical page multiple times may have
|
|
|
|
* caching disabled.
|
|
|
|
*/
|
|
|
|
#define ZERO_REGION_SIZE PAGE_SIZE
|
|
|
|
|
2014-08-05 09:44:10 +00:00
|
|
|
#define SFBUF
|
2014-08-10 16:59:39 +00:00
|
|
|
#define SFBUF_MAP
|
2014-08-23 18:11:54 +00:00
|
|
|
#define SFBUF_OPTIONAL_DIRECT_MAP dcache_color_ignore
|
|
|
|
#include <machine/tlb.h>
|
|
|
|
#define SFBUF_PHYS_DMAP(x) TLB_PHYS_TO_DIRECT(x)
|
2014-08-05 09:44:10 +00:00
|
|
|
|
Add skeleton machine dependent headers and c files for a port of freebsd
to a new architecture. This is the base of the sparc64 port, but contains
limited machine dependent code, and can be used a base for ports. Included
are:
- standard machine dependent headers, tweaked for a 64 bit, big endian
architecture, including empty versions of all the machine dependent
structures
- a machine independent atomic.h, which can be used until a port has
support for interrupts and the operations really need to be atomic
- stub versions of all the machine dependent functions, which panic
when called and print out the name of the function that needs to
be implemented. functions which are normally in assembly files are
not included, but this should reduce the number of different undefined
references on the first few compiles from hundreds to 5 or 6
Given minimal startup code and console support it should be trivial to
make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
2001-07-31 05:45:16 +00:00
|
|
|
#endif /* !_MACHINE_VMPARAM_H_ */
|