CVSROOT:        /cvs
Module name:    src
Changes by:     d...@cvs.openbsd.org    2025/05/20 07:51:27

Modified files:
        sys/arch/amd64/amd64: vmm_machdep.c 
        sys/dev/vmm    : vmm.c vmm.h 
        usr.sbin/vmd   : vm.c 

Log message:
Back vmm(4) guest memory with UVM aobjs.

For the past few years, vmm(4) would require vmd(8) to allocate
virtual memory via mmap(2) in the vm process to use as guest physical
memory. Then vmm(4) would create a new virtual address space itself
to represent the guest and use uvm_share() to share map entries
between them. This worked, but the userland dance of mmap/munmap
to "find" space for guest memory and then having to teardown a full
virtual address space not tied to a process caused some havoc in
state management and potential race conditions.

This commit simplifies how guest memory is represented and managed:

1. vmd(8) no longer calls mmap(2) to find memory for a vm. vmm(4)
creates UVM aobjs to represent the memory ranges and maps them
into the vmd process.

2. vmm(4) no longer faults pages into the vm's address space managed
in the kernel and instead faults directly into the vmd userland
process's address space. Nested page tables (EPT/RVI) are managed
explicitly with pmap(9) functions.

3. vmd(8) shares guest memory between processes (e.g. virtio network
& block devices) using the same ioctl as before, but vmm(4) now
uses uvm_map(9) to map the aobj's into the new process.

4. The aobj mappings into the userland processes are now marked
immutable.

Tested with help from many: bluhm@, kirill@, hshoexer@, Jesper
Wallin, xse[at]krkrkr.org.

Thanks to Mischa Peters for providing access to an additional testing
environment.

Help from mpi@ on uvm aobj lifecycle management.

ok mlarkin@

Reply via email to