summaryrefslogtreecommitdiffstats
path: root/sys/amd64/amd64/mem.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC 307332,312086: Drop support for using mmap() with /dev/kmem.jhb2017-01-181-4/+3
| | | | | | | | | | | | | | | | | | | 307332: Drop support for using mmap() with /dev/kmem. Using the device pager with /dev/kmem is not stable since KVA mappings are transient, but the device pager caches the PA associated with a given offset forever. Interestingly, mips' implementation of memmap() already refused requests for /dev/kmem. Note that kvm_read/kvm_write do not use mmap, but use read and write on /dev/kmem, so this should not affect libkvm users. 312086: Trim a few comments on platforms that did not implement mmap of /dev/kmem. After r307332, no platforms implement mmap for /dev/kmem, so the lack of it for these platforms is no longer unique.
* MFC 303753,308004: Add bounds checking on addresses used with /dev/mem.jhb2016-12-021-3/+5
| | | | | | | | | | | 303753: Don't permit mappings of invalid physical addresses on amd64 via /dev/mem. 308004: MFamd64: Add bounds checks on addresses used with /dev/mem. Reject attempts to read from or memory map offsets in /dev/mem that are beyond the maximum-supported physical address of the current CPU.
* Revert r263475: TDP_DEVMEMIO no longer needed, since amd64 /dev/kmemkib2015-01-121-3/+1
| | | | | | | | does not access kernel mappings directly. Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Fix several issues with /dev/mem and /dev/kmem devices on amd64.kib2015-01-121-47/+55
| | | | | | | | | | | | | | | | | | | | | | | For /dev/mem, when requested physical address is not accessible by the direct map, do temporal remaping with the caching attribute 'uncached'. Limit the accessible addresses by MAXPHYADDR, since the architecture disallowes writing non-zero into reserved bits of ptes (or setting garbage into NX). For /dev/kmem, only access existing kernel mappings for direct map region. For all other addresses, obtain a physical address of the mapping and fall back to the /dev/mem mechanism. This ensures that /dev/kmem i/o does not fault even if the accessed region is changed in parallel, by using either direct map or temporal mapping. For both devices, operate on one page by iteration. Do not return error if any bytes were moved around, return the (partial) bytes count to userspace. Reviewed by: alc Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week
* For /dev/mem and /dev/kmem accesses, avoid asserting that addresseskib2015-01-031-2/+2
| | | | | | | are within direct map. We want to return error instead of panicing. PR: 194995 Sponsored by: The FreeBSD Foundation
* Callers of pmap_kextract() cannot distinguish between failure andkib2015-01-021-7/+7
| | | | | | | | | | | | physical address zero. Assume that the lowest page is always mapped by direct map. This restores access to the page at zero through /dev/mem after r263475. Reported and tested by: neel Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Actually remove GIANT_REQUIRED, declared but not done in r263475.kib2015-01-021-4/+1
| | | | | | | Style. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Fix two issues with /dev/mem access on amd64, both causing kernel pagekib2014-03-211-12/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | faults. First, for accesses to direct map region should check for the limit by which direct map is instantiated. Second, for accesses to the kernel map, success returned from the kernacc(9) does not guarantee that consequent attempt to read or write to the checked address succeed, since other thread might invalidate the address meantime. Add a new thread private flag TDP_DEVMEMIO, which instructs vm_fault() to return error when fault happens on the MAP_ENTRY_NOFAULT entry, instead of panicing. The trap handler would then see a page fault from access, and recover in normal way, making /dev/mem access safer. Remove GIANT_REQUIRED from the amd64 memrw(), since it is not needed and having Giant locked does not solve issues for amd64. Note that at least the second issue exists on other architectures, and requires similar patching for md code. Reported and tested by: clusteradm (gjb, sbruno) Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Partially revert r217515 so that the mem_range_softc variable is alwaysjhb2012-07-091-2/+0
| | | | | | | present on x86 kernels. This fixes the build of kernels that include 'device acpi' but do not include 'device mem'. MFC after: 1 month
* Add reader/writer lock around mem_range_attr_get() and mem_range_attr_set().jkim2011-01-171-7/+2
| | | | | | | | | Compile sys/dev/mem/memutil.c for all supported platforms and remove now unnecessary dev_mem_md_init(). Consistently define mem_range_softc from mem.c for all platforms. Add missing #include guards for machine/memdev.h and sys/memrange.h. Clean up some nearby style(9) nits. MFC after: 1 month
* Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.rnoland2009-12-291-2/+2
| | | | | | | | | | | | | This replaces d_mmap() with the d_mmap2() implementation and also changes the type of offset to vm_ooffset_t. Purge d_mmap2(). All driver modules will need to be rebuilt since D_VERSION is also bumped. Reviewed by: jhb@ MFC after: Not in this lifetime...
* Replace all calls to minor() with dev2unit().ed2008-09-271-4/+4
| | | | | | | | | | | | | | | After I removed all the unit2minor()/minor2unit() calls from the kernel yesterday, I realised calling minor() everywhere is quite confusing. Character devices now only have the ability to store a unit number, not a minor number. Remove the confusion by using dev2unit() everywhere. This commit could also be considered as a bug fix. A lot of drivers call minor(), while they should actually be calling dev2unit(). In -CURRENT this isn't a problem, but it turns out we never had any problem reports related to that issue in the past. I suspect not many people connect more than 256 pieces of the same hardware. Reviewed by: kib
* Make preparations for increasing the size of the kernel virtualalc2008-06-201-1/+1
| | | | | | | | | | address space on the amd64 architecture. The amd64 architecture requires kernel code and global variables to reside in the highest 2GB of the 64-bit virtual address space. Thus, KERNBASE cannot change. However, KERNBASE is sometimes used as the start of the kernel virtual address space. Henceforth, VM_MIN_KERNEL_ADDRESS should be used instead. Since KERNBASE and VM_MIN_KERNEL_ADDRESS are still the same address, there should be no visible effect from this change (yet).
* Minimize diffs with i686_mem.c:jhb2008-03-121-0/+5
| | | | | - A few whitespace changes I missed in the style(9) changes. - Move M_MEMDESC to mem.c.
* Move the definition of M_MEMDESC to a non-optional file. This allowsscottl2004-08-071-5/+0
| | | | kernels configurations without the 'mem' device to compile.
* Fix module builds for i386 and amd64.markm2004-08-041-37/+0
|
* Diff reduction WRT i386 version.markm2004-08-021-11/+12
|
* Fix the build by providing 'PHYS_TO_DMAP' and 'M_MEMDESC'.obrien2004-08-021-0/+6
|
* Break out the MI part of the /dev/[k]mem and /dev/io drivers intomarkm2004-08-011-141/+27
| | | | | | | | their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
* Do the dreaded s/dev_t/struct cdev */phk2004-06-161-6/+6
| | | | Bump __FreeBSD_version accordingly.
* Add missing <sys/module.h> instances which were shadowed by the nestedphk2004-06-031-0/+1
| | | | include in <sys/kernel.h>
* Remove advertising clause from University of California Regent's license,imp2004-04-051-4/+0
| | | | | | per letter dated July 22, 1999. Approved by: core
* Device megapatch 4/6:phk2004-02-211-1/+2
| | | | | | | | Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
* Various whitespace and cosmetic sync-up's with i386.peter2003-12-061-2/+3
| | | | Approved by: re (scottl)
* Initial landing of SMP support for FreeBSD/amd64.peter2003-11-171-0/+9
| | | | | | | | | | | | | | | | - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
* Use __FBSDID().obrien2003-07-251-3/+5
| | | | Brought to you by: a boring talk at Ottawa Linux Symposium
* - Allow access to direct mapped region via /dev/kmem. This makessimokawa2003-06-221-13/+16
| | | | | 'netstat -r' work. - Use direct map for /dev/mem.
* Major pmap rework to take advantage of the larger address space on amd64peter2003-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | systems. Of note: - Implement a direct mapped region using 2MB pages. This eliminates the need for temporary mappings when getting ptes. This supports up to 512GB of physical memory for now. This should be enough for a while. - Implement a 4-tier page table system. Most of the infrastructure is there for 128TB of userland virtual address space, but only 512GB is presently enabled due to a mystery bug somewhere. The design of this was heavily inspired by the alpha pmap.c. - The kernel is moved into the negative address space(!). - The kernel has 2GB of KVM available. - Provide a uma memory allocator to use the direct map region to take advantage of the 2MB TLBs. - Fixed some assumptions in the bus_space macros about the ability to fit virtual addresses in an 'int'. Notable missing things: - pmap_growkernel() should be able to grow to 512GB of KVM by expanding downwards below kernbase. The kernel must be at the top 2GB of the negative address space because of gcc code generation strategies. - need to fix the >512GB user vm code. Approved by: re (blanket)
* Commit MD parts of a loosely functional AMD64 port. This is based onpeter2003-05-011-16/+7
| | | | | | | | | | | | | | | | | | | | | | a heavily stripped down FreeBSD/i386 (brutally stripped down actually) to attempt to get a stable base to start from. There is a lot missing still. Worth noting: - The kernel runs at 1GB in order to cheat with the pmap code. pmap uses a variation of the PAE code in order to avoid having to worry about 4 levels of page tables yet. - It boots in 64 bit "long mode" with a tiny trampoline embedded in the i386 loader. This simplifies locore.s greatly. - There are still quite a few fragments of i386-specific code that have not been translated yet, and some that I cheated and wrote dumb C versions of (bcopy etc). - It has both int 0x80 for syscalls (but using registers for argument passing, as is native on the amd64 ABI), and the 'syscall' instruction for syscalls. int 0x80 preserves all registers, 'syscall' does not. - I have tried to minimize looking at the NetBSD code, except in a couple of places (eg: to find which register they use to replace the trashed %rcx register in the syscall instruction). As a result, there is not a lot of similarity. I did look at NetBSD a few times while debugging to get some ideas about what I might have done wrong in my first attempt.
* - Removed APTD and associated macros, it is no longer used.jake2003-04-031-2/+0
| | | | | | BANG BANG BANG etc. Sponsored by: DARPA, Network Associates Laboratories
* - Add vm_paddr_t, a physical address type. This is required for systemsjake2003-03-251-1/+1
| | | | | | | | | | | | | | | where physical addresses larger than virtual addresses, such as i386s with PAE. - Use this to represent physical addresses in the MI vm system and in the i386 pmap code. This also changes the paddr parameter to d_mmap_t. - Fix printf formats to handle physical addresses >4G in the i386 memory detection code, and due to kvtop returning vm_paddr_t instead of u_long. Note that this is a name change only; vm_paddr_t is still the same as vm_offset_t on all currently supported platforms. Sponsored by: DARPA, Network Associates Laboratories Discussed with: re, phk (cdevsw change)
* Gigacommit to improve device-driver source compatibility betweenphk2003-03-031-13/+9
| | | | | | | | | | | | | branches: Initialize struct cdevsw using C99 sparse initializtion and remove all initializations to default values. This patch is automatically generated and has been tested by compiling LINT with all the fields in struct cdevsw in reverse order on alpha, sparc64 and i386. Approved by: re(scottl)
* Cleanup of the d_mmap_t interface.mux2003-02-251-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | - Get rid of the useless atop() / pmap_phys_address() detour. The device mmap handlers must now give back the physical address without atop()'ing it. - Don't borrow the physical address of the mapping in the returned int. Now we properly pass a vm_offset_t * and expect it to be filled by the mmap handler when the mapping was successful. The mmap handler must now return 0 when successful, any other value is considered as an error. Previously, returning -1 was the only way to fail. This change thus accidentally fixes some devices which were bogusly returning errno constants which would have been considered as addresses by the device pager. - Garbage collect the poorly named pmap_phys_address() now that it's no longer used. - Convert all the d_mmap_t consumers to the new API. I'm still not sure wheter we need a __FreeBSD_version bump for this, since and we didn't guarantee API/ABI stability until 5.1-RELEASE. Discussed with: alc, phk, jake Reviewed by: peter Compile-tested on: LINT (i386), GENERIC (alpha and sparc64) Runtime-tested on: i386
* Back out M_* changes, per decision of the TRB.imp2003-02-191-2/+2
| | | | Approved by: trb
* Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0.alfred2003-01-211-2/+2
| | | | Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.
* Return an error when r/w is requested on an unsupported device instead ofnjl2002-12-311-0/+3
| | | | | | | looping. Submitted by: Sean Kelly <smkelly@zombie.org> Pointed out by: bde
* Change iov_base's type from `char *' to the standard `void *'. Allmike2002-10-111-1/+1
| | | | | uses of iov_base which assume its type is `char *' (in order to do pointer arithmetic) have been updated to cast iov_base to `char *'.
* A good dose of style.9. No functional change.markm2002-09-211-21/+17
|
* Take a shot at fixing a nasty bug in the pmap changes that I did. Ipeter2002-08-031-1/+1
| | | | | | | | | missed the pmap_kenter/kremove in this file, which leads to read()/write() of /dev/mem using stale TLB entries. (gah!) Fortunately, mmap of /dev/mem wasn't affected, so it wasn't as bad as it could have been. This throws some light on the 'X server affects stability' thread.... Pointed out by: bde
* Change the suser() API to take advantage of td_ucred as well as do ajhb2002-04-011-1/+1
| | | | | | | | | | | | general cleanup of the API. The entire API now consists of two functions similar to the pre-KSE API. The suser() function takes a thread pointer as its only argument. The td_ucred member of this thread must be valid so the only valid thread pointers are curthread and a few kernel threads such as thread0. The suser_cred() function takes a pointer to a struct ucred as its first argument and an integer flag as its second argument. The flag is currently only used for the PRISON_ROOT flag. Discussed on: smp@
* Simple p_ucred -> td_ucred changes to start using the per-thread ucredjhb2002-02-271-2/+2
| | | | reference.
* o Modify device open access control for /dev/mem and friends to userwatson2001-09-261-4/+8
| | | | | | securelevel_gt() instead of direct securelevel variable checks. Obtained from: TrustedBSD Project
* KSE Milestone 2julian2001-09-121-6/+6
| | | | | | | | | | | | | | Note ALL MODULES MUST BE RECOMPILED make the kernel aware that there are smaller units of scheduling than the process. (but only allow one thread per process at this time). This is functionally equivalent to teh previousl -current except that there is a thread associated with each process. Sorry john! (your next MFC will be a doosie!) Reviewed by: peter@freebsd.org, dillon@freebsd.org X-MFC after: ha ha ha ha
* With Alfred's permission, remove vm_mtx in favor of a fine-grained approachdillon2001-07-041-8/+2
| | | | | | | | | (this commit is just the first stage). Also add various GIANT_ macros to formalize the removal of Giant, making it easy to test in a more piecemeal fashion. These macros will allow us to test fine-grained locks to a degree before removing Giant, and also after, and to remove Giant in a piecemeal fashion via sysctl's on those subsystems which the authors believe can operate without Giant.
* Add a new MI pointer to the process' trapframe p_frame instead of usingjhb2001-06-291-2/+2
| | | | | | various differently named pointers buried under p_md. Reviewed by: jake (in principle)
* Sort includes.jhb2001-05-211-1/+1
|
* Introduce a global lock for the vm subsystem (vm_mtx).alfred2001-05-191-3/+15
| | | | | | | | | | | | | | | | | | | vm_mtx does not recurse and is required for most low level vm operations. faults can not be taken without holding Giant. Memory subsystems can now call the base page allocators safely. Almost all atomic ops were removed as they are covered under the vm mutex. Alpha and ia64 now need to catch up to i386's trap handlers. FFS and NFS have been tested, other filesystems will need minor changes (grabbing the vm lock when twiddling page properties). Reviewed (partially) by: jake, jhb
* Send the remains (such as I have located) of "block major numbers" tophk2001-03-261-1/+0
| | | | the bit-bucket.
* Duh. Fix a fatfingered patch.markm2000-06-251-1/+1
|
* Fix an uninitialised variable and a function return value.markm2000-06-251-1/+4
| | | | Reported by: dillon
OpenPOWER on IntegriCloud