aboutsummaryrefslogtreecommitdiff
path: root/vm
Commit message (Collapse)AuthorAgeFilesLines
* vm_allocate_contiguous: Add missing page unwiring after making the area ↵Samuel Thibault2024-03-041-0/+3
| | | | | | | | | non-pageable Otherwise, if the allocated memory is passed over for returning data such as in device_read, we end up with ../vm/vm_map.c:4245: vm_map_copyin_page_list: Assertion `src_entry->wired_count > 0' failed.Debugger invoked: assertion failure
* vm_map: Add comment and assert for vm_map_deleteDamien Zammit2024-02-231-0/+7
| | | | | | This will prevent calling vm_map_delete without the map locked unless ref_count is zero. Message-ID: <20240223081505.458240-1-damien@zamaudio.com>
* vm_map_lookup: Add parameter for keeping map lockedDamien Zammit2024-02-223-6/+9
| | | | | | | | | | | This adds a parameter called keep_map_locked to vm_map_lookup() that allows the function to return with the map locked. This is to prepare for fixing a bug with gsync where the map is locked twice by mistake. Co-Authored-By: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240222082410.422869-3-damien@zamaudio.com>
* vm_pages_phys: Avoid faults while we keep vm locksSamuel Thibault2024-02-041-2/+3
| | | | | In principle we are actually writing to the allocated area outside of the vm lock, but better be safe in case somebody changes things.
* Add vm_pages_physSamuel Thibault2024-01-301-0/+100
| | | | | | | | For rumpdisk to efficiently determine the physical address, both for checking whether it is below 4GiB, and for giving it to the disk driver, we need a gnumach primitive (and that is not conditioned by MACH_VM_DEBUG like mach_vm_region_info and mach_vm_object_pages_phys are).
* adjust range when changing memory pageabilityLuca Dariz2024-01-131-5/+26
| | | | | | | | | * vm/vm_map.c: use actual limits instead of min/max boundaries to change pageability of the currently mapped memory. This caused the initial vm_wire_all(host, task VM_WIRE_ALL) in glibc startup to fail with KERN_NO_SPACE. Message-ID: <20240111210907.419689-5-luca@orpolo.org>
* vm: Coalesce map entriesSergey Bugaev2023-11-271-2/+27
| | | | | | | | When - extending an existing entry, - changing protection or inheritance of a range of entries, we can get several entries that could be coalesced. Attempt to do that. Message-ID: <20230705141639.85792-4-bugaevc@gmail.com>
* vm: Add vm_map_coalesce_entrySergey Bugaev2023-11-272-2/+78
| | | | | | This function attempts to coalesce a VM map entry with its preceeding entry. It wraps vm_object_coalesce. Message-ID: <20230705141639.85792-3-bugaevc@gmail.com>
* ddb: Add whatis commandSamuel Thibault2023-10-011-0/+4
| | | | This is convenient when tracking buffer overflows
* vm_page_bootalloc: Return a phys_addr_tSamuel Thibault2023-08-293-3/+4
|
* vm_page: Fix setting higher bits in physical addressesSamuel Thibault2023-08-291-2/+2
|
* mach_vm_object_pages: Extend for PAESamuel Thibault2023-08-281-20/+69
|
* vm_allocate_contiguous: Accept returning end of allowed memorySamuel Thibault2023-08-281-1/+1
| | | | | *result_paddr + size is exactly pass the allocated memory, so it can be equal to the requested bound.
* typoSamuel Thibault2023-08-281-1/+1
|
* vm_allocate_contiguous: better handle pmaxSamuel Thibault2023-08-211-4/+8
| | | | | | In case pmax is inside a segment, we should avoid using it, and stay with the previous segment, thus being sure to respect the caller's constraints.
* vm: Also check for virtual addresses in vm_map_deleteSamuel Thibault2023-08-141-0/+3
|
* vm: Fix ordering of addresses between DMA32 and DIRECTMAPSamuel Thibault2023-08-143-4/+28
|
* Fix missing DMA32 limitSamuel Thibault2023-08-091-0/+8
| | | | | | | | | | | Rumpdisk needs to allocate dma32 memory areas, so we do always need this limit. The non-Xen x86_64 case had a typo, and the 32bit PAE case didn't have the DMA32 limit. Also, we have to cope with VM_PAGE_DMA32_LIMIT being either above or below VM_PAGE_DIRECTMAP_LIMIT depending on the cases.
* vm: Make vm_object_coalesce return new object and offsetSergey Bugaev2023-07-053-19/+49
| | | | | | | | | | | | | | | | | | | vm_object_coalesce() callers used to rely on the fact that it always merged the next_object into prev_object, potentially destroying next_object and leaving prev_object the result of the whole operation. After ee65849bec5da261be90f565bee096abb4117bdd "vm: Allow coalescing null object with an internal object", this is no longer true, since in case of prev_object == VM_OBJECT_NULL and next_object != VM_OBJECT_NULL, the overall result is next_object, not prev_object. The current callers are prepared to deal with this since they handle this case seprately anyway, but the following commit will introduce another caller that handles both cases in the same code path. So, declare the way vm_object_coalesce() coalesces the two objects its implementation detail, and make it return the resulting object and the offset into it explicitly. This simplifies the callers, too. Message-Id: <20230705141639.85792-2-bugaevc@gmail.com>
* vm: Eagerly release deallocated pagesSergey Bugaev2023-07-031-5/+21
| | | | | | | | | | | | | | If a deallocated VM map entry refers to an object that only has a single reference and doesn't have a pager port, we can eagerly release any physical pages that were contained in the deallocated range. This is not a 100% solution: it is still possible to "leak" physical pages that can never appear in virtual memory again by creating several references to a memory object (perhaps by forking a VM map with VM_INHERIT_SHARE) and deallocating the pages from all the maps referring to the object. That being said, it should help to release the pages in the common case sooner. Message-Id: <20230626112656.435622-6-bugaevc@gmail.com>
* vm: Allow coalescing entries forwardSergey Bugaev2023-07-031-4/+35
| | | | | | | When entering an object into a map, try to extend the next entry backward, in addition to the previously existing attempt to extend the previous entry forward. Message-Id: <20230626112656.435622-5-bugaevc@gmail.com>
* vm: Allow coalescing null object with an internal objectSergey Bugaev2023-07-031-26/+49
| | | | | | | | | | | | | | | Previously, vm_object_coalesce would only succeed with next_object being VM_OBJECT_NULL (and with the previous patch, with the two object references pointing to the same object). This patch additionally allows the inverse: prev_object being VM_OBJECT_NULL and next_object being some internal VM object that we have not created a pager port for, provided the offset of the existing mapping in the object allows for placing the new mapping before it. This is not used anywhere at the moment (the only caller, vm_map_enter, ensures that next_object is either VM_OBJECT_NULL or an object that has a pager port), but it will get used with the next patch. Message-Id: <20230626112656.435622-4-bugaevc@gmail.com>
* vm: Allow coalescing a VM object with itselfSergey Bugaev2023-07-032-11/+23
| | | | | | | | If a mapping of an object is made right next to another mapping of the same object have the same properties (protection, inheritance, etc.), Mach will now expand the previous VM map entry to cover the new address range instead of creating a new entry. Message-Id: <20230626112656.435622-3-bugaevc@gmail.com>
* Shrink struct vm_page sizeSergey Bugaev2023-07-033-9/+15
| | | | | | | | | | | | | | | | | | | | | | struct vm_page is supposed to be a "small structure", but it takes up 96 bytes on x86_64 (to represent a 4k page). By utilizing bitfields and strategically reordering members to avoid excessive padding, it can be shrunk to 80 bytes. - page_lock and unlock_request only need to store a bitmask of VM_PROT_READ, VM_PROT_WRITE, and VM_PROT_EXECUTE. Even though the special values VM_PROT_NO_CHANGE and VM_PROT_NOTIFY are defined, they are not used for the two struct vm_page members. - type and seg_index both need to store one of the four possible values in the range from 0 to 3. Two bits are sufficient for this. - order needs to store a number from 0 to VM_PAGE_NR_FREE_LISTS (which is 11), or a special value VM_PAGE_ORDER_UNLISTED. Four bits are sufficient for this. No functional change. Message-Id: <20230626112656.435622-2-bugaevc@gmail.com>
* memory_object_create_proxy: avoid casting parameters to 32 bits since the ↵Flavio Cruz2023-02-091-7/+0
| | | | | | types are correct now Message-Id: <Y+SfNtIRuwj0Zap1@jupiter.tail36e24.ts.net>
* vm_page.c: add missing object lockEtienne Brateau2023-02-091-0/+1
| | | | | | The documentation of vm_page_insert says that the object must be locked. Moreover, the unlock call is here but no call was present. Message-Id: <20230208225436.23365-1-etienne.brateau@gmail.com>
* slock: Fix initialization of statically-allocated slocksSamuel Thibault2023-02-083-5/+5
| | | | (this is actually a no-op for i386)
* Define rpc_vm_size_array_t and rpc_vm_offset_array_tFlavio Cruz2023-01-313-17/+10
| | | | | | | | | | When generating stubs, Mig will will take the vm_size_array_t and define the input request struct using rpc_vm_size_t since the size is variable. This will turn cause a mismatch between types (vm_size_t* vs rpc_vm_size_t*). We could also ask Mig to produce a prototype by using rpc_vm_size_t*, however we would need to change the implementation of the RPC to use rpc_* types anyway since we want to avoid another allocation of the array. Message-Id: <Y9iwScHpmsgY3V0N@jupiter.tail36e24.ts.net>
* Fix several warnings for -Wmissing-prototypes (part 2)Flavio Cruz2023-01-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | * i386/i386/io_map.c: code is unused. * i386/i386/io_perm.c: include mig prototypes. * i386/i386/mp_desc.c: Deleted interrupt_stack_alloc since it is not used. * i386/i386/seg.h: Moved descriptor structs to i386/include/mach/i386/mach_i386_types.h as that represents the interface types for RPCs. Defined aliases for real_descriptor since those are used by the i386 RPCs. Inlined many functions here too and removed seg.c. * i386/i386/seg.c: Removed. All the functions are inline now. * i386/i386/trap.c: Use static. * i386/i386/trap.h: Define missing prototypes. * i386/i386/tss.h: Use static inline for ltr. * i386/i386/user_ldt.c: Include mig prototypes. * i386/include/mach/i386/mach_i386.defs: Define real_descriptor_t types since those are used in the RPC definition. Now both prototypes and definitions will match. * i386/include/mach/i386/mach_i386_types.h: Move struct descriptor from seg.h since we need those for the RPC interfaces. Removed include of io_perm.h since it generates circular includes otherwise. * i386/intel/pmap.c: pmap_map is unused. Added static qualifier for several functions. * i386/intel/pmap.h: pmap_update_interrupt declared for non-SMP and SMP. Message-Id: <Y89+R2VekOQK4IUo@jupiter.lan>
* Remove existing old style definitions and use -Wold-style-definition.Flavio Cruz2023-01-194-9/+5
| | | | Message-Id: <Y8mYd/pt/og4Tj5I@mercury.tail36e24.ts.net>
* Include mig generated headers to avoid warnings with -Wmissing-prototypes.Flavio Cruz2023-01-195-3/+9
| | | | | | This also reverts 566c227636481b246d928772ebeaacbc7c37145b and 963b1794d7117064cee8ab5638b329db51dad854 Message-Id: <Y8d75KSqNL4FFInm@mercury.tail36e24.ts.net>
* Add static qualifiersFlavio Cruz2023-01-181-1/+1
| | | | | stack_statistics, swapin_thread_continue, and memory_object_lock_page are not used outside their module.
* Create kern/mach4.h and kern/mach_host.h and define the RPC prototypes for ↵Flavio Cruz2023-01-131-0/+1
| | | | | | | mach4.defs and mach_host.defs. Also move more mach_debug rpcs to kern/mach_debug.h. Message-Id: <Y7+LPMLOafUQrNHZ@jupiter.tail36e24.ts.net>
* Fix some warnings with -Wmissing-prototypes.Flavio Cruz2022-12-277-92/+16
| | | | | | | | | | | Marked some functions as static (private) as needed and added missing includes. This also revealed some dead code which was removed. Note that -Wmissing-prototypes is not enabled here since there is a bunch more warnings. Message-Id: <Y6j72lWRL9rsYy4j@mars>
* Warn only once about not being able to recycle pagesSamuel Thibault2022-12-221-1/+9
|
* Use -Wstrict-prototypes and fix warningsFlavio Cruz2022-12-218-38/+40
| | | | | | | Most of the changes include defining and using proper function type declarations (with argument types declared) and avoiding using the K&R style of function declarations. Message-Id: <Y6Jazsuis1QA0lXI@mars>
* vm_page_evict: avoid crashingSamuel Thibault2022-12-181-1/+1
| | | | | | It seems we hit he "unable to recycle any page" even when there is no memory pressure, probably just because the pageout thread somehow to kicked but there's nothing to page out left.
* Use __builtin_ffs instead of libc provided ffs in vm_map.cFlavio Cruz2022-12-151-2/+2
| | | | | | We already use this built-in in other places and this will move us closer to being able to build the kernel without libc. Message-Id: <Y5l80/VUFvJYZTjy@jupiter.tail36e24.ts.net>
* Define vm_size_t and vm_offset_t as __mach_uintptr_t.Flavio Cruz2022-12-062-5/+5
| | | | | | | | | | This allows *printf to use %zd/%zu/%zx to print vm_size_t and vm_offset_t. Warnings using the incorrect specifiers were fixed. Note that MACH_PORT_NULL became just 0 because GCC thinks that we were comparing a pointer to a character (due to it being an unsigned int) so I removed the explicit cast. Message-Id: <Y47UNdcUF35Ag4Vw@reue>
* vm_wire_all: Fix vm_map_protect caseSamuel Thibault2022-11-271-1/+2
| | | | | | | | | | | If a "wire_required" process calls vm_map_protect(0), the memory gets unwired as expected. But if the process then calls vm_map_protect(VM_PROT_READ) again, we need to wire that memory. (This happens to be exactly what glibc does for its heap) This fixes Hurd hangs on lack of memory, during which mach was swapping pieces of mach-defpager out.
* hack vm memory object proxy creation for vm arraysLuca Dariz2022-08-281-0/+7
| | | | | | | | | | | | | | | | * vm/memory_object_proxy.c: truncate vm array types as if they were the rpc_ version because MIG can't handle that. This rpc can't handle more than one element anyway. Note that the same issue with vm arrays is present at least with syscall emulation, but that functionality seems unused for now. A better fix could be to add a vm descriptor type in include/mach/message.h, but then probably we don't need to use the rpc_ types in MIG anymore, they would be needed only for the syscall definitions. Signed-off-by: Luca Dariz <luca@orpolo.org> Message-Id: <20220628101054.446126-15-luca@orpolo.org>
* sign-extend mask in vm_map() with 32-bit userspaceLuca Dariz2022-08-281-0/+5
| | | | | | | * vm/vm_user.c: sign-extend mask with USER32 Signed-off-by: Luca Dariz <luca@orpolo.org> Message-Id: <20220628101054.446126-6-luca@orpolo.org>
* fix warnings for 32 bit buildsLuca Dariz2022-08-272-1/+2
| | | | | Signed-off-by: Luca Dariz <luca@orpolo.org> Message-Id: <20220628101054.446126-13-luca@orpolo.org>
* gnumach: vm_allocate_contiguous: Allow small power 2 alignmentsDamien Zammit2022-08-211-0/+4
| | | | | | | | | | This allows contiguous allocations aligned to values smaller than one page, but still a power of 2, by forcing the alignment to be to the nearest page. This works because PAGE_SIZE is a power of two. Message-Id: <20220821065732.269573-1-damien@zamaudio.com>
* vm_object_page_map: update prototypeSamuel Thibault2022-02-181-1/+1
|
* vm_allocate_contiguous: fix checking the end of the allocationSamuel Thibault2022-02-171-1/+1
|
* mach_vm_object_pages: Print a warning if the physical address is beyond 4GiBSamuel Thibault2022-02-171-0/+2
| | | | vpi_offset is not currently large enough to store it.
* vm_allocate_contiguous: Make sure we enforce physical addresses contraintsSamuel Thibault2022-02-171-0/+3
|
* projected_buffer_*: Fix storing physical addressSamuel Thibault2022-02-171-3/+5
|
* vm_object: Fix vm_object_page_map map function prototypeSamuel Thibault2022-02-161-2/+2
| | | | The map function is supposed to return physical addresses, thus phys_addr_t.
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-08 14:45:04 +0000