Revision tags: release/12.4.0 |
|
#
892feec2 |
| 15-Nov-2022 |
Corvin Köhne <corvink@FreeBSD.org> |
vmm: avoid spurious rendezvous
A vcpu only checks if a rendezvous is in progress or not to decide if it should handle a rendezvous. This could lead to spurios rendezvous where a vcpu tries a handle
vmm: avoid spurious rendezvous
A vcpu only checks if a rendezvous is in progress or not to decide if it should handle a rendezvous. This could lead to spurios rendezvous where a vcpu tries a handle a rendezvous it isn't part of. This situation is properly handled by vm_handle_rendezvous but it could potentially degrade the performance. Avoid that by an early check if the vcpu is part of the rendezvous or not.
At the moment, rendezvous are only used to spin up application processors and to send ioapic interrupts. Spinning up application processors is done in the guest boot phase by sending INIT SIPI sequences to single vcpus. This is known to cause spurious rendezvous and only occurs in the boot phase. Sending ioapic interrupts is rare because modern guest will use msi and the rendezvous is always send to all vcpus.
Reviewed by: jhb MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D37390
show more ...
|
#
c668e817 |
| 20-Jan-2023 |
Robert Wing <rew@FreeBSD.org> |
vmm: take exclusive mem_segs_lock in vm_cleanup()
The consumers of vm_cleanup() are vm_reinit() and vm_destroy().
The vm_reinit() call path is, here vmmdev_ioctl() takes mem_segs_lock: vmmdev_i
vmm: take exclusive mem_segs_lock in vm_cleanup()
The consumers of vm_cleanup() are vm_reinit() and vm_destroy().
The vm_reinit() call path is, here vmmdev_ioctl() takes mem_segs_lock: vmmdev_ioctl() vm_reinit() vm_cleanup(destroy=false)
The call path for vm_destroy() is (mem_segs_lock not taken): sysctl_vmm_destroy() vmmdev_destroy() vm_destroy() vm_cleanup(destroy=true)
Fix this by taking mem_segs_lock in vm_cleanup() when destroy == true.
Reviewed by: corvink, markj, jhb Fixes: 67b69e76e8ee ("vmm: Use an sx lock to protect the memory map.") Differential Revision: https://reviews.freebsd.org/D38071
show more ...
|
#
af3b48e1 |
| 09-Dec-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Free vCPUs when destroying them.
Reported by: andrew Reviewed by: corvink, andrew, markj Differential Revision: https://reviews.freebsd.org/D37649
|
#
fde8ce88 |
| 17-Nov-2022 |
Corvin Köhne <corvink@FreeBSD.org> |
vmm: remove unneccessary rendezvous assertion
When a vcpu sees that a rendezvous is in progress, it exits and tries to handle the rendezvous. The vcpu doesn't check if it's part of the rendezvous or
vmm: remove unneccessary rendezvous assertion
When a vcpu sees that a rendezvous is in progress, it exits and tries to handle the rendezvous. The vcpu doesn't check if it's part of the rendezvous or not. If the vcpu isn't part of the rendezvous, the rendezvous could be done before it reaches the assertion. This will cause a panic.
The assertion isn't needed at all because vm_handle_rendezvous properly handles a spurious rendezvous. So, we can just remove it.
PR: 267779 Reviewed by: jhb, markj Tested by: bz Approved by: manu (mentor) MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D37417
show more ...
|
#
ee98f99d |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Convert VM_MAXCPU into a loader tunable hw.vmm.maxcpu.
The default is now the number of physical CPUs in the system rather than 16.
Reviewed by: corvink, markj Differential Revision: https://r
vmm: Convert VM_MAXCPU into a loader tunable hw.vmm.maxcpu.
The default is now the number of physical CPUs in the system rather than 16.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37175
show more ...
|
#
98568a00 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Allocate vCPUs on first use of a vCPU.
Convert the vcpu[] array in struct vm to an array of pointers and allocate vCPUs on first use. This avoids always allocating VM_MAXCPU vCPUs for each VM,
vmm: Allocate vCPUs on first use of a vCPU.
Convert the vcpu[] array in struct vm to an array of pointers and allocate vCPUs on first use. This avoids always allocating VM_MAXCPU vCPUs for each VM, but instead only allocates the vCPUs in use. A new per-VM sx lock is added to serialize attempts to allocate vCPUs on first use. However, a given vCPU is never freed while the VM is active, so the pointer is read via an unlocked read first to avoid the need for the lock in the common case once the vCPU has been created.
Some ioctls need to lock all vCPUs. To prevent races with ioctls that want to allocate a new vCPU, these ioctls also lock the sx lock that protects vCPU creation.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37174
show more ...
|
#
c0f35dbf |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Use a cpuset_t for vCPUs waiting for STARTUP IPIs.
Retire the boot_state member of struct vlapic and instead use a cpuset in the VM to track vCPUs waiting for STARTUP IPIs. INIT IPIs add vCPUs
vmm: Use a cpuset_t for vCPUs waiting for STARTUP IPIs.
Retire the boot_state member of struct vlapic and instead use a cpuset in the VM to track vCPUs waiting for STARTUP IPIs. INIT IPIs add vCPUs to this set, and STARTUP IPIs remove vCPUs from the set. STARTUP IPIs are only reported to userland for vCPUs that were removed from the set.
In particular, this permits a subsequent change to allocate vCPUs on demand when the vCPU may not be allocated until after a STARTUP IPI is reported to userland.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37173
show more ...
|
#
67b69e76 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Use an sx lock to protect the memory map.
Previously bhyve obtained a "read lock" on the memory map for ioctls needing to read the map by locking the last vCPU. This is now replaced by a new p
vmm: Use an sx lock to protect the memory map.
Previously bhyve obtained a "read lock" on the memory map for ioctls needing to read the map by locking the last vCPU. This is now replaced by a new per-VM sx lock. Modifying the map requires exclusively locking the sx lock as well as locking all existing vCPUs. Reading the map requires either locking one vCPU or the sx lock.
This permits safely modifying or querying the memory map while some vCPUs do not exist which will be true in a future commit.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37172
show more ...
|
#
08ebb360 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Destroy mutexes.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37171
|
#
3f0f4b15 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Lookup vcpu pointers in vmmdev_ioctl.
Centralize mapping vCPU IDs to struct vcpu objects in vmmdev_ioctl and pass vcpu pointers to the routines in vmm.c. For operations that want to perform an
vmm: Lookup vcpu pointers in vmmdev_ioctl.
Centralize mapping vCPU IDs to struct vcpu objects in vmmdev_ioctl and pass vcpu pointers to the routines in vmm.c. For operations that want to perform an action on all vCPUs or on a single vCPU, pass pointers to both the VM and the vCPU using a NULL vCPU pointer to request global actions.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37168
show more ...
|
#
e42c24d5 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Remove unused vcpuid argument from vioapic_process_eoi.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37166
|
#
d8be3d52 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Use struct vcpu in the rendezvous code.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37165
|
#
949f0f47 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Remove support for vm_rendezvous with a cpuid of -1.
This is not currently used.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37164
|
#
80cb5d84 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Pass vcpu instead of vm and vcpuid to APIs used from CPU backends.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37162
|
#
d3956e46 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Use struct vcpu in the instruction emulation code.
This passes struct vcpu down in place of struct vm and and integer vcpu index through the in-kernel instruction emulation code. To minimize u
vmm: Use struct vcpu in the instruction emulation code.
This passes struct vcpu down in place of struct vm and and integer vcpu index through the in-kernel instruction emulation code. To minimize userland disruption, helper macros are used for the vCPU arguments passed into and through the shared instruction emulation code.
A few other APIs used by the instruction emulation code have also been updated to accept struct vcpu in the kernel including vm_get/set_register and vm_inject_fault.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37161
show more ...
|
#
28b561ad |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Add vm_gpa_hold_global wrapper function.
This handles the case that guest pages are being held not on behalf of a virtual CPU but globally. Previously this was handled by passing a vcpuid of -
vmm: Add vm_gpa_hold_global wrapper function.
This handles the case that guest pages are being held not on behalf of a virtual CPU but globally. Previously this was handled by passing a vcpuid of -1 to vm_gpa_hold, but that will not work in the future when vm_gpa_hold is changed to accept a struct vcpu pointer.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37160
show more ...
|
#
2b4fe856 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
bhyve: Remove unused vm and vcpu arguments from vm_copy routines.
The arguments identifying the VM and vCPU are only needed for vm_copy_setup.
Reviewed by: corvink, markj Differential Revision: htt
bhyve: Remove unused vm and vcpu arguments from vm_copy routines.
The arguments identifying the VM and vCPU are only needed for vm_copy_setup.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37158
show more ...
|
#
3dc3d32a |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Use struct vcpu with the vmm_stat API.
The function callbacks still use struct vm and and vCPU index.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37157
|
#
950af9ff |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Expose struct vcpu as an opaque type.
Pass a pointer to the current struct vcpu to the vcpu_init callback and save this pointer in the CPU-specific vcpu structures.
Add routines to fetch a str
vmm: Expose struct vcpu as an opaque type.
Pass a pointer to the current struct vcpu to the vcpu_init callback and save this pointer in the CPU-specific vcpu structures.
Add routines to fetch a struct vcpu by index from a VM and to query the VM and vcpuid from a struct vcpu.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37156
show more ...
|
#
869c8d19 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Remove the per-vm cookie argument from vmmops taking a vcpu.
This requires storing a reference to the per-vm cookie in the CPU-specific vCPU structure. Take advantage of this new field to remo
vmm: Remove the per-vm cookie argument from vmmops taking a vcpu.
This requires storing a reference to the per-vm cookie in the CPU-specific vCPU structure. Take advantage of this new field to remove no-longer-needed function arguments in the CPU-specific backends. In particular, stop passing the per-vm cookie to functions that either don't use it or only use it for KTR traces.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37152
show more ...
|
#
1aa51504 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Refactor storage of CPU-dependent per-vCPU data.
Rather than storing static arrays of per-vCPU data in the CPU-specific per-VM structure, adopt a more dynamic model similar to that used to mana
vmm: Refactor storage of CPU-dependent per-vCPU data.
Rather than storing static arrays of per-vCPU data in the CPU-specific per-VM structure, adopt a more dynamic model similar to that used to manage CPU-specific per-VM data.
That is, add new vmmops methods to init and cleanup a single vCPU. The init method returns a pointer that is stored in 'struct vcpu' as a cookie pointer. This cookie pointer is now passed to other vmmops callbacks in place of the integer index. The index is now only used in KTR traces and when calling back into the CPU-independent layer.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37151
show more ...
|
#
39ec056e |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Rework snapshotting of CPU-specific per-vCPU data.
Previously some per-vCPU state was saved in vmmops_snapshot and other state was saved in vmmops_vcmx_snapshot. Consolidate all per-vCPU state
vmm: Rework snapshotting of CPU-specific per-vCPU data.
Previously some per-vCPU state was saved in vmmops_snapshot and other state was saved in vmmops_vcmx_snapshot. Consolidate all per-vCPU state into the latter routine and rename the hook to the more generic 'vcpu_snapshot'. Note that the CPU-independent per-vCPU data is still stored in a separate blob as well as the per-vCPU local APIC data.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37150
show more ...
|
#
35abc6c2 |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Use vm_get_maxcpus() instead of VM_MAXCPU in various places.
Mostly these are loops that iterate over all possible vCPU IDs for a specific virtual machine.
Reviewed by: corvink, markj Differen
vmm: Use vm_get_maxcpus() instead of VM_MAXCPU in various places.
Mostly these are loops that iterate over all possible vCPU IDs for a specific virtual machine.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37147
show more ...
|
#
a7db532e |
| 18-Nov-2022 |
John Baldwin <jhb@FreeBSD.org> |
vmm: Simplify saving of absolute TSC values in snapshots.
Read the current "now" TSC value and use it to compute absolute time saved value in vm_snapshot_vcpus rather than iterating over vCPUs multi
vmm: Simplify saving of absolute TSC values in snapshots.
Read the current "now" TSC value and use it to compute absolute time saved value in vm_snapshot_vcpus rather than iterating over vCPUs multiple times in vm_snapshot_vm.
Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37146
show more ...
|
#
4d447b30 |
| 01-Nov-2022 |
Konstantin Belousov <kib@FreeBSD.org> |
vmm: do not leak halted_cpus bit after suspension
Reported by: bz PR: 267468 Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.
vmm: do not leak halted_cpus bit after suspension
Reported by: bz PR: 267468 Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D37227
show more ...
|