This chapter describes allocating memory andthe low-level routines for modifying memory maps in the kernel.It also describes a number of commonly used interfaces to the virtualmemory system. It does not describe how to make changes in pagingpolicy or add additional pagers. OS X does not support externalpagers, althoughmuch of the functionality can be achieved in other ways, some ofwhich are covered at a high level in this chapter. The implementationdetails of these interfaces are subject to change, however, andare thus left undocumented.
With the exception of the section Allocating Memory in the Kernel,this chapter is of interest only if you are writing file systemsor are modifying the virtual memory system itself.
Virtual Machine Disk is the 'containers' for virtual hard disk drives to be used in virtual machines like VMware Workstation or VirtualBox. In simpler terms, just like the hard disk for your PC or Mac, a Virtual Disk is a disk drive for virtualization software. It is a container.
OS X VM Overview
- The virtual machine can then run alongside your normal Mac apps, such as Apple Mail and Safari, allowing you to run Windows and Mac apps on the Mac desktop at the same time.
- To change the screen size of the virtual machine on VirtualBox, follow the steps below in order. To change the macOS display resolution in VBox, you need to use the following code. In the 'Your VM' section of the code, you must type the name of your macOS virtual machine.
- In this article, you will learn how to Fix macOS Mojave screen resolution on VMware on Windows. However, you need that every year Mac or Apple is releasing a new operating system. Or upgrading the old version of macOS to the latest version. Certainly, you installed macOS Mojave on VMware and VirtualBox and done the VMware Tools also.
The VM systemused in OS X is a descendent of Mach VM, which was created at CarnegieMellon University in the 1980s. To a large extent, the fundamentaldesign is the same, although some of the details are different,particularly when enhancing the VM system. It does, however, supportthe ability to request certain paging behavior through the use of universalpage lists (UPLs). See Universal Page Lists (UPLs) formore information.
The design of Mach VM centers around the concept of physicalmemory being a cache for virtual memory.
Running Mac Os In Vm
At its highest level, Mach VM consists of address spaces andways to manipulate the contents of those address spaces from outsidethe space. These address spaces are sparse and have a notion ofprotections to limit what taskscan access their contents.
At a lower level, the object level, virtual memory is seenas a collection of VM objects and memory objects, each with a particular owner andprotections. These objects can be modified with object calls thatare available both to the task and (via the back end of the VM)to the pagers.
Note: Whilememory objects and VM objects are closely related, the terms arenot equivalent and should not be confused. A VM object can be backedby one or more memory objects, which are, in turn, managed by apager. A VM object may also be partially backed by other VM objects,as occurs in the case of shadow chains (described later in thissection).
The VM object is internal to the virtual memory system, andincludes basic information about accessing the memory. The memoryobject, by contrast, is provided by the pager. The contents of thememory associated with that memory object can be retrieved fromdisk or some other backing store by exchanging messages with thememory object. Implicitly, each VM object is associated with a givenpager through its memory object.
VM objects are cached with system pages (RAM), which can beany power of two multiple of the hardware page size. In the OS X kernel, system pages are the same size as hardware pages. Eachsystem page is represented in a given address space by a map entry. Eachmap entry has its own protection and inheritance. A given map entrycan have an inheritance of shared, copy,or none. If a page ismarked shared in a givenmap, child tasks share this page for reading and writing. If a pageis marked copy, childtasks get a copy of this page (using copy-on-write). If a page ismarked none, the child'spage is left unallocated.
VM objects are managed by the machine-independent VM system,with the underlying virtual to physical mappings handled by themachine-dependent pmapsystem. The pmap systemactually handles page tables, translation lookaside buffers, segments,and so on, depending on the design of the underlying hardware.
When a VM object is duplicated (for example,the data pages from a process that has just called fork),a shadow object is created. A shadow object is initiallyempty, and contains a reference to another object. When the contentsof a page are modified, the page is copied from the parent objectinto the shadow object and then modified. When reading data from apage, if that page exists in the shadow object, the page listedin the shadow object is used. If the shadow object has no copy ofthat page, the original object is consulted. A series of shadowobjects pointing to shadow objects or original objects is knownas a shadow chain.
Shadow chains can become arbitrarily long if an object isheavily reused in a copy-on-write fashion. However, since fork isfrequently followed by exec,which replaces all of the material being shadowed, long chains arerare. Further, Mach automatically garbage collects shadow objects,removing any intermediate shadow objects whose pages are no longerreferenced by any (nondefunct) shadow object. It is even possiblefor the original object to be released if it no longer containspages that are relevant to the chain.
The VM calls available to an application include vm_map and vm_allocate,which can be used to map file data or anonymous memory into theaddress space. This is possible only because the address space isinitially sparse. In general, an application can either map a file intoits address space (through file mapping primitives, abstracted byBSD) or it can map an object (after being passed a handle to thatobject). In addition, a task can change the protections of the objectsin its address space and can share those objects with other tasks.
In addition to the mapping and allocation aspects of virtualmemory, the VM system contains a number of other subsystems. Theseinclude the back end (pagers) and the shared memory subsystem. Thereare also other subsystems closely tied to VM, including the VM sharedmemory server. These are described in Other VM and VM-Related Subsystems.
Memory Maps Explained
Each Mach task has its own memory map. In Mach, this memorymap takes the form of an ordered doubly linked list. As describedin OS X VM Overview,each of these objects contains a list of pages and shadow referencesto other objects.
In general, you should never need to access a memory map directlyunless you are modifying something deep within the VM system. The vm_map_entry structurecontains task-specific information about an individual mapping alongwith a reference to the backing object. In essence, it is the gluebetween an VM object and a VM map.
While the details of this data structure are beyond the scopeof this document, a few fields are of particular importance.
The field is_submap isa Boolean value that tells whether this map entry is a normal VM objector a submap.A submap is a collection of mappings that is part of a larger map. Submapsare often used to group mappings together for the purpose of sharingthem among multiple Mach tasks, but they may be used for many purposes.What makes a submap particularly powerful is that when several taskshave mapped a submap into their address space, they can see eachother's changes, not only to the contents of the objects in themap, but to the objects themselves. This means that as additionalobjects are added to or deleted from the submap, they appear inor disappear from the address spaces of all tasks that share thatsubmap.
The field behavior controlsthe paging reference behavior of a specified range in a given map.This value changes how pageins are clustered. Possible values are VM_BEHAVIOR_DEFAULT, VM_BEHAVIOR_RANDOM, VM_BEHAVIOR_SEQUENTIAL,and VM_BEHAVIOR_RSEQNTL,for default, random, sequential, or reverse-sequential pagein ordering.
The protection and max_protection fieldscontrol the permissions on the object. The protection fieldindicates what rights the task currently has for the object, whilethe max_protection fieldcontains the maximum access that the current task can obtain forthe object.
You might use the protection fieldwhen debugging shared memory. By setting the protection to be read-only,any inadvertent writes to the shared memory would cause an exception.However, when the task actually needs to write to that shared region,it could increase its permissions in the protection fieldto allow writes.
It would be a security hole if a task could increaseits own permissions on a memory object arbitrarily, however. Inorder to preserve a reasonable security model, the task that owns amemory object must be able to limit the rights granted to a subordinatetask. For this reason, a task is not allowed to increase its protectionbeyond the permissions granted in max_protection.
Possible values for protection and max_protection aredescribed in detail in xnu/osfmk/mach/vm_prot.h.
Finally, the use_pmap fieldindicates whether a submap's low-level mappings should be sharedamong all tasks into which the submap is mapped. If the mappingsare not shared, then the structure of the map is shared among alltasks, but the actual contents of the pages are not.
For example, shared libraries are handled withtwo submaps. The read-only shared code section has use_pmap setto true. The read-write (nonshared) section has use_pmap setto false, forcing a clean copy of the library's DATA segmentto be mapped in from disk for each new task.
Named Entries
The OS X VM system provides an abstraction known as a namedentry. Anamed entry is nothing more than a handle to a shared object ora submap.
Shared memory support in OS X is achieved by sharing objectsbetween the memory maps of various tasks. Shared memory objectsmust be created from existing VM objects by calling vm_allocate toallocate memory in your address space and then calling mach_make_memory_entry_64 toget a handle to the underlying VM object.
The handle returned by mach_make_memory_entry_64 canbe passed to vm_map tomap that object into a given task's address space. The handlecan also be passed via IPC or other means to other tasks so thatthey can map it into their address spaces. This provides the abilityto share objects with tasks that are not in your direct lineage,and also allows you to share additional memory with tasks in yourdirect lineage after those tasks are created.
The other form of named entry, the submap, is used to groupa set of mappings. The most common use of a submap is to share mappingsamong multiple Mach tasks. A submap can be created with vm_region_object_create.
What makes a submap particularly powerful is that when severaltasks have mapped a submap into their address space, they can seeeach other's changes to both the data and the structure of themap. This means that one task can map or unmap a VM object in another task'saddress space simply by mapping or unmapping that object in thesubmap.
UniversalPage Lists (UPLs)
A universal page list, or UPL, is a data structure used whencommunicating with the virtual memory system. UPLs can be used tochange the behavior of pages with respect to caching, permissions,mapping, and so on. UPLs can also be used to push data into and pulldata from VM objects. The term is also often used to refer to thefamily of routines that operate on UPLs. The flags used when dealingwith UPLs are described in osfmk/mach/memory_object_types.h.
The life cycle of a UPL looks like this:
A UPL iscreated based on the contents of a VM object. This UPL includesinformation about the pages within that object.
That UPL is modified in some way.
The changes to the UPL are either committed (pushed back tothe VM system) or aborted, with
ubc_upl_commitorubc_upl_abort,respectively.
If you have a control handle for a given VM object (whichgenerally means that you are inside a pager), you can use vm_object_upl_request toget a UPL for that object. Otherwise, you must use the vm_map_get_upl call.In either case, you are left with a handle to the UPL.
When a pagein is requested, the pager receives a list of pagesthat are locked against the object, with certain pages set to notvalid. The pager must either write data into those pages or mustabort the transaction to prevent invalid data in the kernel. Unity dev kit. Similarlyin pageout, the kernel must write the data to a backing store orabort the transaction to prevent data loss. The pager may also electto bring additional pages into memory or throw additional pagesout of memory at its discretion.
Because pagers can be used both for virtual memory and formemory mapping of file data, when a pageout is requested, the datamay need to be freed from memory, or it may be desirable to keepit there and simply flush the changes to disk. For this reason,the flag UPL_CLEAN_IN_PLACE existsto allow a page to be flushed to disk but not removed from memory.
When a pager decides to page in or out additional pages, itmust determine which pages to move. A pager can request all of thedirty pages by setting the RETURN_ONLY_DIRTY flag. Itcan also request all pages that are not in memory using the RETURN_ONLY_ABSENT flag.
There is a slight problem, however. If a given page is markedas BUSY in the UPL, arequest for information on that page would normally block. If thepager is doing prefetching or preflushing, this is not desirable,since it might be blocking on itself or on some other pager thatis blocked waiting for the current transaction to complete. To avoidsuch deadlock, the UPL mechanism provides the UPL_NOBLOCK flag.This is frequently used in the anonymous pager for requesting freememory.
The flag QUERY_OBJECT_TYPE canbe used to determine if an object is physically contiguous and toget other properties of the underlying object.
The flag UPL_PRECIOUS meansthat there should be only one copy of the data. This prevents havinga copy both in memory and in the backing store. However, this breaksthe adjacency of adjacent pages in the backing store, and is thusgenerally not used to avoid a performance hit.
The flag SET_INTERNAL Nordvpn for mac 10 11. isused by the BSD subsystem to cause all information about a UPL tobe contained in a single memory object so that it can be passedaround more easily. It can only be used if your code is runningin the kernel's address space.
Since this handle can be used for multiple small transactions(for example, when mapping a file into memory block-by-block), theUPL API includes functions for committing and aborting changes toonly a portion of the UPL. These functions are upl_commit_range and upl_abort_range,respectively.
To aid in the use of UPLs for handling multi-part transactions,the upl_commit_range and upl_abort_range callshave a flag that causes the UPL to be freed when there are no unmodifiedpages in the UPL. If you use this flag, you must be very carefulnot to use the UPL after all ranges have been committed or aborted.
Finally, the function vm_map_get_upl isfrequently used in file systems. It gets the underlying VM objectassociated with a given range within an address space. Since this returnsonly the first object in that range, it is your responsibility todetermine whether the entire range is covered by the resulting UPLand, if not, to make additional calls to get UPLs for other objects.Note that while the vm_map_get_upl callis against an address space range, most UPL callsare against a vm_object.
Using Mach Memory Maps
Warning: This section describes the low-level API for dealingwith Mach VM maps. Thesemaps cannot be modified in this way from a kernel extension. Thesefunctions are not available for use in a KEXT. They are presentedstrictly for use within the VM system and other parts of Mach. Ifyou are not doing in-kernel development, you should be using themethods described in the chapter Boundary Crossings.
From the context of the kernel (not froma KEXT), there are two maps that you will probably need to dealwith. The first is the kernel map. Since your code is executingin the kernel's address space, no additional effort is neededto use memory referenced in the kernel map. However, you may needto add additional mappings into the kernel map and remove them whenthey are no longer needed.
The second map of interest is the memory map for a given task.This is of most interest for code that accepts input from user programs,for example a sysctl ora Mach RPC handler. In nearly all cases, convenient wrappers providethe needed functionality, however.
Most of these functions are based around the vm_offset_t type, which is a pointer-sized integer. In effect, you can think of them as pointers, with the caveat that they are not necessarily pointers to data in the kernel's address space, depending on usage.
The low-level VM map API includes the following functions:
The function vm_map_copyin copiesdata from an arbitrary (potentially non–kernel) memory map intoa copy list and returns the copy list pointer in copy_result.If something goes wrong and you need to throw away this intermediateobject, it should be freed with vm_map_copy_discard.
In order to actually get the data from the copy list, youneed to overwrite a memory object in the kernel's address spacewith vm_map_copy_overwrite. This overwritesan object with the contents of a copy list. For most purposes, thevalue passed for interruptible should be FALSE,and pmap should be NULL.
Copying data from the kernel to user space is exactly thesame as copying data from user space, except that you pass kernel_map to vm_map_copyin andpass the user map to vm_map_copy_overwrite.In general, however, you should avoid doing this, since you could endup with a task's memory being fragmented into lots of tiny objects,which is undesirable.
Do not use vm_map_copyout whencopying data into an existing user task's address map. The function vm_map_copyout isused for filling an unused region in an address map. If the regionis allocated, then vm_map_copyout doesnothing. Because it requires knowledge of the current state of themap, it is primarily used when creating a new address map (for example,if you are manually creating a new process). For most purposes,you do not need to use vm_map_copyout.
The functions vm_map_wire and vm_map_unwire canbe used to wire and unwire portions of an address map. If you setthe argument user_wire to TRUE,then the page can be unwired from user space. This should be setto FALSE if you are aboutto use the memory for I/O or for some other operation that cannottolerate paging. In vm_map_wire,the argument access_type indicatesthe types of accesses that should not be allowed to generate a page fault.In general, however, you should be using vm_wire towire memory.
As mentioned earlier, this information is presented strictlyfor use in the heart of the kernel. You cannot use anythingin this section from a kernel extension.
Other VM and VM-Related Subsystems
There are two additional VM subsystems: pagers and the workingset detection subsystem. In addition, the VM shared memory serversubsystem is closely tied to (but is not part of) the VM subsystem.This section describes these three VM and VM-related subsystems.
Pagers
OS X has three basic pagers: the vnode pager, the defaultpager (or anonymous pager), and the device pager. These are usedby the VM system to actually get data into the VM objects that underlienamed entries. Pagers are linked into the VM system through a combinationof a subset of the old Mach pager interface and UPLs.
The default pager is what most peoplethink of when they think of a VM system. It is responsible for movingnormal data into and out of the backing store. In addition, thereis a facility known as the dynamic pager thatsits on top of the default pager and handles the creation and deletionof backing store files. These pager files are filled with data inclusters (groups of pages).
When the total fullness of the paging file pool reaches ahigh–water mark, the default pager asks the dynamic pager to allocatea new store file. When the pool drops below its low water mark,the VM system selects a pager file, moves its contents into otherpager files, and deletes it from disk.
The vnode pager has a 1:1 (onto) mapping betweenobjects in VM space and open files (vnodes). It is used for memorymapped file I/O. The vnode pager is generally hidden behind callsto BSD file APIs.
The device pager allows you to map non–general-purposememory with the cache characteristics required for that memory (WIMG). Non–general–purposememory includes physical addresses that are mapped onto hardwareother than main memory—for example, PCI memory, frame buffer memory,and so on. The device pager is generally hidden behind calls tovarious I/O Kit functions.
Working Set Detection Subsystem
To improve performance, OS X has a subsystem known asthe working set detection subsystem. This subsystem is called ona VM fault; it keeps a profile of the fault behavior of each taskfrom the time of its inception. In addition, just before a pagerequest, the fault code asks this subsystem which adjacent pagesshould be brought in, and then makes a single large request to thepager.
Since files on disk tend to have fairly good locality, andsince address space locality is largely preserved in the backingstore, this provides a substantial performance boost. Also, sinceit is based upon the application's previous behavior, it tendsto pull in pages that would probably have otherwise been neededlater. This occurs for all pagers.
The working set code works well once it is established. However,without help, its performance would be the baseline performanceuntil a profile for a given application has been developed. To overcomethis, the first time that an application is launched in a given usercontext, the initial working set required to start the applicationis captured and stored in a file. From then on, when the applicationis started, that file is used to seed the working set.
These working set files are established on a per-user basis.They are stored in /var/vm/app_profile andare only accessible by the super-user (and the kernel).
VM Shared Memory Server Subsystem
The VM shared memory serversubsystem is a BSD service that is closely tied to VM, but is notpart of VM. This server provides two submaps that are used for sharedlibrary support in OS X. Because shared libraries containboth read-only portions (text segment) and read-write portions (datasegment), the two portions are treated separately to maximize efficiency.The read-only portions are completely shared between tasks, includingthe underlying pmap entries.The read-write portions share a common submap, but have differentunderlying data objects (achieved through copy-on-write).
The three functions exported by the VM shared memory serversubsystem should only be called by dyld.Do not use them in your programs.
The function load_shared_file isused to load a new shared library into the system. Once such a fileis loaded, other tasks can then depend on it, so a shared librarycannot be unshared. However, a new set of shared regions can becreated with new_system_shared_regions sothat no new tasks will use old libraries.
The function reset_shared_file canbe used to reset any changes that your task may have made to itsprivate copy of the data section for a file.
Finally, the function new_system_shared_regions canbe used to create a new set of shared regions for future tasks.New regions can be used when updating prebinding with new sharedlibraries to cause new tasks to see the latest libraries at theirnew locations in memory. (Users of old shared libraries will stillwork, but they will fall off the pre-bound path and will performless efficiently.) It can also be used when dealing with private librariesthat you want to share only with your task's descendents.
Address Spaces
This section explains issues that some developers may seewhen using their drivers in Panther or later. These changes werenecessitated by a combination of hardware and underlying OS changes;however, you may see problems resulting from the changes even onexisting hardware.
There are three basic areas of change in OS X v10.3. Theseare:
IOMemoryDescriptorchangesVM system (
pmap)changesKernel dependency changes
These are described in detail in the sections that follow.
Background Info on PCI AddressTranslation
To allow existing device drivers to work with upcoming 64-bitsystem architectures, a number of changes were required. To explainthese, a brief introduction to PCI bus bridges is needed.
When a PCI device needs to perform a data transaction to orfrom main memory, the device driver calls a series of functionsintended to prepare this memory for I/O. In an architecture whereboth the device drivers and the memory subsystem use 32-bit addressing,everything just works, so long as the memory doesn't get paged outduring the I/O operation. As kernel memory is generally not pageable,the preparation is largely superfluous.
On a system whose memory subsystem uses 64-bit addressing,however, this becomes a bit of a problem. Because the hardware deviceson the PCI bus can only handle 32-bit addresses, the device canonly 'see' a 4 gigabyte aperture into the (potentially much larger)main memory at any given time.
There are two possible solutions for this problem. The easy(but slow) solution would be to use 'bounce buffers'. In sucha design, device drivers would copy data into memory specificallyallocated within the bottom 4 gigs of memory. However, this incursa performance penalty and also puts additional constraints on thelower 4 gigs of memory, causing numerous problems for the VM system.
The other solution, the one chosen in Apple's 64-bit implementation,is to use address translation to 'map' blocks of memory intothe 32-bit address space of the PCI devices. While the PCI devicecan still only see a 4 gig aperture, that aperture can then be non-contiguous,and thus bounce buffers and other restrictions are unnecessary.This address translation is done using a part of the memory controllerknown as DART, which stands for Device Address Resolution Table.
This introduces a number of potential problems, however. First,physical addresses as seen by the processor no longer map 1:1 ontothe addresses as seen by PCI devices. Thus, a new term, I/O addresses,is introduced to describe this new view. Because I/O addresses and physicaladdresses are no longer the same, the DART must keep a table oftranslations to use when mapping between them. Fortunately, if yourdriver is written according to Apple guidelines (using only documentedAPIs), this process is handled transparently.
Note: Thisadditional addressing mode has an impact when debugging I/O Kitdevice drivers. For more information, see When Things Go Wrong: Debugging the Kernel.
IOMemoryDescriptor Changes
When your driver calls IOMemoryDescriptor::prepare,a mapping is automatically injected into the DART. When it calls IOMemoryDescriptor::release ,the mapping is removed. If you fail to do this, your driver couldexperience random data corruption or panics.
Because the DART requires different caching for reads andwrites, the DMA direction is important on hardware that includesa DART. While you may receive random failures if the directionis wrong in general (on any system), if you attempt to call WriteByteson a memory region whose DMA direction is set up for reading, youwill cause a kernel panic on 64-bit hardware.
If you attempt to perform a DMA transaction to unwired (user) memory, on previous systems, you would only get random crashes, panics, and data corruption. On machines with a DART, you will likely get no data whatsoever.
As a side-effect of changes in the memory subsystem, OS X is much more likely to return physically contiguous page rangesin memory regions. Historically, OS X returned multi-pagememory regions in reverse order, starting with the last page and moving towards the first page. The result of this was that multi-page memory regions essentially never had a contiguous range of physical pages.
Because of the increased probability of seeing physically contiguous blocks of memory in a memory region, this change may expose latent bugs in some drivers that only show up when handling contiguous ranges of physical pages, which could result in incorrect behavior or panics.
Note that the problems mentioned above are caused by bugsin the drivers, and could result in problems on older hardware priorto Panther. These issues are more likely to occur in Panther andlater versions of OS X, however, because of the new hardware designsand the OS changes that were made to support those designs.
VM System and pmap Changes:
In Panther, as a result of the changes described in detailin the section on PCI address translation, physical addresses obtaineddirectly from the pmap layerhave no useful purpose outside the VM system itself. To preventtheir inadvertent use in device drivers, the pmap callsare no longer available from kernel extensions.
A few drivers written prior to the addition of the IOMemoryDescriptor classstill use pmap callsto get the physical pages associated with a virtual address. Also,a few developers have looked at the IOMemoryDescriptor implementationand chosen to obtain addresses directly from the pmap layer to remove what was perceived as an unnecessary abstraction layer.
Even without removing access to the pmap calls,these drivers would not function on systems with a DART (see thePCI section above for info on DARTs). To better emphasize this upcomingfailure, Panther will cause these drivers to fail to load with anundefined symbol error (generally for pmap_extract )even on systems without a DART.
Kernel Dependency Changes
Beginning in Panther, device drivers that declare a dependencyon version 7 (the Panther version) of the I/O Kit will no longerautomatically get symbols from Mach and BSD. This change was madeto discourage I/O Kit developers from relying on symbols that arenot explicitly approved for use in the I/O Kit.
Existing drivers are unaffected by this change. This changeonly affects you if you explicitly modify your device driver todeclare a dependency on version 7 of the I/O Kit to take advantageof new I/O Kit features.
Summary
As described above, some device drivers may require minormodifications to support Panther and higher. Apple has made everyeffort to ensure compatibility with existing device drivers to thegreatest extent possible, but a few drivers may break. If your driver breaks,you should first check to see if your driver includes any of thebugs described in the previous sections. If it does not, contactApple Developer Technical Support for additional debugging suggestions.
Allocating Memory in the Kernel
As with most things in the OS X kernel, there are a number of ways to allocate memory. The choice of routines depends both on the location of the calling routine and on the reason for allocating memory. In general, you should use Mach routines for allocating memory unless you are writing code for use in the I/O Kit, in which case you should use I/O Kit routines.
Allocating Memory From a Non-I/O-Kit Kernel Extension
The header defines the following routines for kernel memory allocation:
OSMalloc—allocates a block of memory.OSMalloc_noblock—allocates a block of memory, but immediately returns NULL if the request would block. Game psp iso dibawah 100 mb.OSMalloc_nowait—same asOSMalloc_noblock.OSFree—releases memory allocated with any of theOSMallocvariants.OSMalloc_Tagalloc—allows you to create a unique tag for your memory allocations. Youmustcreate at least one tag before you can use any of theOSMallocfunctions.OSMalloc_Tagfree—releases a tag allocated with OSMalloc_Tagalloc. (You must release all allocations associated with that tag before you call this function.)
For example, to allocate and free a page of wired memory, you might write code like this:
To allocate a page of pageable memory, pass OSMT_PAGEABLE instead of OSMT_DEFAULT in your call to OSMalloc_Tagalloc.
Hyper-v Mac Os Vm
Allocating Memory From the I/O Kit
Although the I/O Kit is generally beyond the scope of this document, the I/O Kit memory management routines are presented here for completeness. In general, I/O Kit routines should not be used outside the I/O Kit. Similarly, Mach allocation routines should not be directly used from the I/O Kit because the I/O Kit has abstractions for those routines that fit the I/O Kit development model more closely.
The I/O Kit includes the following routines for kernel memory allocation:
Most of these routines are relatively transparent wrappers around the Mach allocation functions. There are two major differences, however. First, the caller does not need to know which memory map is being modified. Second, they have a separate free call for each allocation call for internal bookkeeping reasons.
The functions IOMallocContiguous and IOMallocAligned differ somewhat from their Mach underpinnings. IOMallocAligned uses calls directly to Mach VM to add support for arbitrary (power of 2) data alignment, rather than aligning based on the size of the object. IOMallocContiguous adds an additional parameter, PhysicalAddress. If this pointer is not NULL, the physical address is returned through this pointer. Using Mach functions, obtaining the physical address requires a separate function call.
Important: If your KEXT allocates memory that will be shared, you should create a buffer of type IOMemoryDescriptor or IOBufferMemoryDescriptor and specify that the buffer should be sharable. If you are allocating memory in a user application that will be shared with the kernel, you should use valloc or vm_allocate instead of malloc and then call mach_make_memory_entry_64.
Allocating Memory In the Kernel Itself
In addition to the routines available to kernel extensions, there are a number of other functions you can call to allocate memory when you are modifying the Mach kernel itself. Mach routines provide a relatively straightforward interface for allocating and releasing memory. They are the preferred mechanism for allocating memory outside of the I/O Kit. BSD also offers _MALLOC and _FREE, which may be used in BSD parts of the kernel.
These routines do not provide for forced mapping of a given physical address to a virtual address. However, if you need such a mapping, you are probably writing a device driver, in which case you should be using I/O Kit routines instead of Mach routines.
Most of these functions are based around the vm_offset_t type, which is a pointer-sized integer. In effect, you can think of them as pointers, with the caveat that they are not necessarily pointers to data in the kernel's address space, depending on usage.
These are some of the commonly used Mach routines for allocating memory:
These functions all take a map as the first argument. Unlessyou need to allocate memory in a different map, you should pass kernel_map forthis argument.
All of the kmem_alloc functionsexcept kmem_alloc_pageable allocatewired memory. The function kmem_alloc_pageable createsthe appropriate VM structures but does not back the region withphysical memory. This function could be combined with vm_map_copyout when creatinga new address map, for example. In practice, it is rarely used.
The function kmem_alloc_aligned allocatesmemory aligned according to the value of the size argument,which must be a power of 2.
The function kmem_alloc_wired issynonymous with kmem_alloc andis appropriate for data structures that cannot be paged out. Itis not strictly necessary; however, if you explicitly need certainpieces of data to be wired, using kmem_alloc_wired makesit easier to find those portions of your code.
https://bestcload314.weebly.com/4k-youtube-to-mp3-3-0-0-download-free.html. The function kmem_alloc_contig attemptsto allocate a block of physically contiguous memory. This is notalways possible, and requires a full sort of the system free listeven for short allocations. After startup, this sort can cause longdelays, particularly on systems with lots of RAM. You should generallynot use this function.
The function kmem_free isused to free an object allocated with one of the kmem_alloc functions.Unlike the standard C free function, kmem_free requiresthe length of the object. If you are not allocating fixed-size objects(for example, sizeof struct foo),you may have to do some additional bookkeeping, since you must freean entire object, not just a portion of one.
Copyright © 2002, 2013 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2013-08-08
It happened to me today: I created a Virtualbox (free) Virtual Machine (VM) to run some tests (moving an old PC to a VM), and I have underestimated the disk size that I really needed: with 15GB, the OS (Windows 7) didn't even have enough space to update itself. No biggie, I can re-size the disk in a click right? Not really.
(Unlike VMWare) There is no graphical user interface to change that particular setting. But fret not, here's how to do it quickly with the command line for both Windows and Mac. First, make a backup copy of your VM!
Technical details
- The 'new graphical user interface section was added using VirtualBox 6 (May 2020)
- This was written using VirtualBox 4.3.22 on Windows and 4.3.20 on Mac (Feb 2015)
- The virtual machine has a dynamically allocated disk (which means that the .VDI file will grow over time)
- The VM OS is Windows 7
New graphical user interface to resize
In more recent version of VirtualBox, you have a Virtual Media Manager that cab resize the disk for you (I spotted it in V6.x but I'm unsure as for when it was added). It is very simple as you just go to the File menu and select it.
Then choose the disk you want to modify, and pick a new size following by 'Apply'. But that's not over! This new graphical user interface basically lets you skip Step 1 to Step 4 in the instructions below.
Run Mac Os In Vm
It is equivalent to increasing the size of a physical disk, but you still need to extend the Operating System partition, as described in Step 5 onwards.
Windows
Step 1
Open a command prompt by clicking on its icon or typing 'cmd' in Start>Search.
Step 2
Go where VirtualBox is installed (typically C:Program FilesOracleVirtualBox) to find the VboxManage utility (full documentation here). Here are the commands to type (one per line):
Mac Vm Iso
cd
cd 'Program FilesOracleVirtualBox'
You should now be in the proper directory, and can even verify that the VBoxManage.exe app is there by typing
dir VboxManage.exe
Step 3
Find the file path where your virtual machine disk file (.vdi) is (usually in C:UsersVirtualBox VMs).
Step 4
Use the modifyhd command of VBoxManage (a utility that comes with VirtualBox) as follows:
VBoxManage modifyhd 'C:UsersVirtualBox VMs.vdi' –resize
In my case, I typed (to re-size to 40 GB or 40000 MB):
VBoxManage modifyhd 'c:UsersHubertVirtualBox VMsAccounting CloneAccounting Windows Clone.vdi' –resize 40000
The quotes enclosing is necessary because the file path (and name) has spaces in it, and the Prompt would not be able to handle them without the quotes.
Note: that's TWO dashes before 'resize'. Depending on your font, it may visually appear as one long line.
You should see a visual confirmation that VBoxManage is working on the file. The time to get this done depends on the size, but it should be a matter of minutes. Virtual box will now confirm that the drive is larger (here, it's 40GB as we asked)
Step 5
Boot into your virtual machine, and you will realize that the drive still appears as being the same size as before (here, 15GB) !!! It's normal — this is just because although the disk has been re-sized, the partition is still set up with its original size. We can fix it.
Step 6
Go to the disk management by doing Start>Computer (right-click)>Manage>Storage>Disk Management. (you can also open it from the command-line)
Step 7
Right-click on the existing partition you want to extend (here, C:) and choose 'Extend Volume' in the pop-up menu.
By default, the Disk Manager will propose that you extend to all the available space, which is what you probably want to do, but you can pick any other size you want. The screenshot below shows that we're adding 24GB to the existing 15GB => nearly 40GB.
And if all goes well, a new look at the C: drive now shows the 40GB we asked for. There you go. You can finally use the extra space!
Just in case, here's also a video (not mine) that shows what the process looks like. It uses a slightly different version of Windows, but that should be close enough:
Mac OS X
Step 1
If you use Mac OS, the procedure is almost exactly the same. I'll make this a little shorter for time's sake. I know that some users have never used the command prompt (learn more about the OSX prompt), so here's how to find it: just search for Terminal app.
Step 2
Locate the full path and file name of your virtual machine .VDI virtual disk file. You will need both to enter the command in Terminal.
Step 3
It seems that the VBoxManage app is available from any location by default, so we don't need to go to the App's directory. Just the command as follow in the terminal Window:
VBoxManage modifyhd '' –resize 40000
You should see the utility work on the file in the command prompt.
When it is done, restart the VM and boot into Windows. From there, just pick up at the Windows solution, Step 5 as shown above.
You will need to re-size the Windows partition, and you will have enough storage to suit your needs. That's it!
Misc
Note that I'm assuming that you absolutely need space on the system drive here. I did because I wanted updates to work and I needed to install more apps on C:.
If you want storage for data, you could also add another D: drive by building a new emulated disk. In general, I find it easier to manage my VMs as single files, but if there's data sharing, it makes sense to share disks.
If you know a better/easier way of doing this, let us know in the comments. We hope that this saved a few minutes to someone out there!
Mac Vm Image
Filed in . Read more about Mac Os and Windows.
