#
99127fd1 |
| 05-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
libvmmapi: Use the vmmctl device file to create and destroy VMs
This deprecates the vm_create() and vm_open() interfaces and introduces vm_openf(), which takes flags controlling its behaviour. In p
libvmmapi: Use the vmmctl device file to create and destroy VMs
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
show more ...
|
Revision tags: release/13.4.0, release/14.1.0 |
|
#
56a26fc1 |
| 03-Apr-2024 |
Mark Johnston <markj@FreeBSD.org> |
libvmmapi: Conditionalize compilation of some functions
Hide definitions of several functions that currently don't have implementatations in the arm64 vmm port. In particular, add a WITH_VMMAPI_SNA
libvmmapi: Conditionalize compilation of some functions
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
show more ...
|
#
7e0fa794 |
| 03-Apr-2024 |
Mark Johnston <markj@FreeBSD.org> |
libvmmapi: Make memory segment handling a bit more abstract
libvmmapi leaves a hole at [3GB, 4GB) in the guest physical address space. This hole is not used in the arm64 port, which maps everything
libvmmapi: Make memory segment handling a bit more abstract
libvmmapi leaves a hole at [3GB, 4GB) in the guest physical address space. This hole is not used in the arm64 port, which maps everything above 4GB. This change makes the code a bit more general to accomodate arm64 more naturally. In particular:
- Remove vm_set_lowmem_limit(): it is unused and doesn't have well-defined constraints, e.g., nothing prevents a consumer from setting a lowmem limit above the highmem base. - Define a constant for the highmem base and use that everywhere that the base is currently hard-coded. - Make the lowmem limit a compile-time constant instead of a vmctx field. - Store segment info in an array. - Add vm_get_highmem_base(), for use in bhyve since the current value is hard-coded in some places.
No functional change intended.
Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D41004
show more ...
|
#
7f00e46b |
| 03-Apr-2024 |
Mark Johnston <markj@FreeBSD.org> |
libvmmapi: Split the ioctl list into MI and MD lists
To enable use in capability mode, libvmmapi needs a list of all the ioctls that might be invoked on the vmm device handle. Some of these ioctls
libvmmapi: Split the ioctl list into MI and MD lists
To enable use in capability mode, libvmmapi needs a list of all the ioctls that might be invoked on the vmm device handle. Some of these ioctls are amd64-specific. Move the ioctl list to vmmapi_machdep.c and define a list of MI ioctls so that the arm64 port can build its own list without duplicating common ioctls. No functional change intended.
Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D41001
show more ...
|
#
85efb31d |
| 03-Apr-2024 |
Mark Johnston <markj@FreeBSD.org> |
libvmmapi: Move VM capability names to vmmapi_machdep.c
Add some missing entries while here.
Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://re
libvmmapi: Move VM capability names to vmmapi_machdep.c
Add some missing entries while here.
Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D41000
show more ...
|
#
e4656e10 |
| 03-Apr-2024 |
Mark Johnston <markj@FreeBSD.org> |
libvmmapi: Move some ioctl wrappers to vmmapi_machdep.c
ioctls relating to segments and various x86-specific interrupt controllers are easy candidates to move to vmmapi_machdep.c.
In vmmapi.h I'm j
libvmmapi: Move some ioctl wrappers to vmmapi_machdep.c
ioctls relating to segments and various x86-specific interrupt controllers are easy candidates to move to vmmapi_machdep.c.
In vmmapi.h I'm just ifdefing MD prototypes for now. We could instead split vmmapi.h into multiple headers, e.g., vmmapi.h and vmmapi_machdep.h, but it's not obvious to me yet that that's the right approach.
No functional change intended.
Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40999
show more ...
|
Revision tags: release/13.3.0, release/14.0.0, release/13.2.0 |
|
#
7d9ef309 |
| 24-Mar-2023 |
John Baldwin <jhb@FreeBSD.org> |
libvmmapi: Add a struct vcpu and use it in most APIs.
This replaces the 'struct vm, int vcpuid' tuple passed to most API calls and is similar to the changes recently made in vmm(4) in the kernel.
s
libvmmapi: Add a struct vcpu and use it in most APIs.
This replaces the 'struct vm, int vcpuid' tuple passed to most API calls and is similar to the changes recently made in vmm(4) in the kernel.
struct vcpu is an opaque type managed by libvmmapi. For now it stores a pointer to the VM context and an integer id.
As an immediate effect this removes the divergence between the kernel and userland for the instruction emulation code introduced by the recent vmm(4) changes.
Since this is a major change to the vmmapi API, bump VMMAPI_VERSION to 0x200 (2.0) and the shared library major version.
While here (and since the major version is bumped), remove unused vcpu argument from vm_setup_pptdev_msi*().
Add new functions vm_suspend_all_cpus() and vm_resume_all_cpus() for use by the debug server. The underyling ioctl (which uses a vcpuid of -1) remains unchanged, but the userlevel API now uses separate functions for global CPU suspend/resume.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D38124
show more ...
|