FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2025-12-17T14:08:32Z 2025-12-17T14:08:32Z Bojan Novković bnovkov@FreeBSD.org 2025-11-06T14:26:27Z urn:sha1:bd16bac27e7e0d31bccf88feca95cd98f0ef0fd4 This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine on close using the `VMMCTL_CREATE_DESTROY_ON_CLOSE` flag when creating the virtual machine. `vmmctl` tracks such virtual machines in per-descriptor lists. Differential Revision: https://reviews.freebsd.org/D53729 Reviewed by: markj Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months 2025-07-27T16:31:48Z Bojan Novković bnovkov@FreeBSD.org 2024-09-08T15:57:55Z urn:sha1:08c7dd2fbe4fb7ae5cd6943afef04bd4cb350c1f This patch reworks libvmmapi to provide support for emulating NUMA domains in guests. More specifically, it reworks 'vm_setup_memory' to setup system memory segments for each guest NUMA domain. An emulated NUMA domain is described by a 'struct vmdom' in vmmapi.h. Aside from its size in bytes, each domain can be configured to use a specific domainset(9) policy and domain mask. 'vm_setup_memory' now takes two additional arguments - an array of struct vmdoms and the array's size. It then proceeds to set up a memory segment for each specified domain using the existing memory mapping scheme. If no domain info is passed, the memory setup falls back to the original, non-NUMA behaviour. Differential Revision: https://reviews.freebsd.org/D44566 Reviewed by: markj 2025-07-27T16:31:48Z Bojan Novković bnovkov@FreeBSD.org 2024-09-08T16:04:33Z urn:sha1:a4197ea477771d525c2970d0c42acab727e43f16 This change adds the necessary kernelspace bits required for supporting NUMA domains in bhyve VMs. The layout of system memory segments and how they're created has been reworked. Each guest NUMA domain will now have its own memory segment. Furthermore, this change allows users to tweak the domain's backing vm_object domainset(9) policy. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D44565 2025-02-06T16:25:42Z Mark Johnston markj@FreeBSD.org 2025-02-06T14:37:46Z urn:sha1:23a28fe7776f6d76643a6ac16758d114dfbbeec2 - We should autoload vmm.ko when creating a VM with vm_openf(), to preserve behaviour prior to commit 99127fd10362. - kldload(2) returns a non-zero value upon success, so the existing code was wrong. Reviewed by: jhb Reported by: olivier Fixes: 99127fd10362 ("libvmmapi: Use the vmmctl device file to create and destroy VMs") Differential Revision: https://reviews.freebsd.org/D48797 2024-12-17T10:35:44Z Ruslan Bukin br@FreeBSD.org 2024-12-17T10:35:24Z urn:sha1:a7bf553d175a27b03cbad7d0f94e40991df2958b Check if RISC-V SSTC is available and advertise to the guest. This is needed for Eswin EIC7700 that does not include SSTC. As we don't have a mechanism for reporting extension presence from the kernel to userspace, then use vm_cap_type for now. Reviewed by: mhorne, markj Differential Revision: https://reviews.freebsd.org/D48058 2024-11-05T01:40:41Z Mark Johnston markj@FreeBSD.org 2024-11-05T01:36:33Z urn:sha1:99127fd103624de593c7d1d885387e7d3667d73d This deprecates the vm_create() and vm_open() interfaces and introduces vm_openf(), which takes flags controlling its behaviour. In particular, it will optionally create a VM first, and it can optionally reinitialize an existing VM. This enables some simplification of existing consumers. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D47030 2024-10-31T20:24:12Z Ruslan Bukin br@FreeBSD.org 2024-10-31T16:14:32Z urn:sha1:7ab1a32cd43cbae61ad4dd435d6a482bbf61cb52 Add machine-dependent parts for bhyve hypervisor to support virtualization on RISC-V ISA. No objection: markj Sponsored by: UK Research and Innovation Differential Revision: https://reviews.freebsd.org/D45512 2024-04-10T15:17:56Z Mark Johnston markj@FreeBSD.org 2024-04-03T17:45:06Z urn:sha1:56a26fc1af60e31732f8913ebe4c058095b6c721 Hide definitions of several functions that currently don't have implementatations in the arm64 vmm port. In particular, add a WITH_VMMAPI_SNAPSHOT preprocessor variable that can be used to enable compilation of save/restore functions, and conditionalize compilation of some functions only used by amd64 bhyve. If in the long term they remain amd64-only, they can move to vmmapi_machdep.c, but for now it's not clear to me that that's the right thing to do. MFC after: 2 weeks Sponsored by: Innovate UK 2024-04-10T15:17:56Z Mark Johnston markj@FreeBSD.org 2024-04-03T17:09:43Z urn:sha1:e499fdcb66b9ef3d9fc3c626daaefe909c65a2ab Avoid assuming that the kernel zeros the name buffer, it does not do this for zero-length segments. MFC after: 2 weeks Sponsored by: Innovate UK 2024-04-10T15:17:56Z Mark Johnston markj@FreeBSD.org 2024-04-03T17:09:32Z urn:sha1:1855002ddf0b226d92ce5d698bae06305d9a3a4e Currently, bhyve PCI emulation uses vm_lapic_msi() to raise an MSI in the guest. The arm64 port has a similar function, vm_raise_msi(). Add vm_raise_msi() on amd64 as well and have it simply call vm_lapic_msi() so that bhyve can use a common, generically named function. Reviewed by: corvink, andrew, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D41752