FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=stable%2F13 2023-12-25T03:58:03Z 2023-12-25T03:58:03Z Konstantin Belousov kib@FreeBSD.org 2023-12-20T23:40:00Z urn:sha1:7f5511c698bc5d1f036067df9470d2045ffcdb9e (cherry picked from commit 7c8f16318499d2b05e916abd66148e5409284a9d) 2023-08-23T17:43:20Z Warner Losh imp@FreeBSD.org 2023-08-22T01:31:02Z urn:sha1:f8167e0404dab9ffeaca95853dd237ab7c587f82 Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/ Similar commit in current: (cherry picked from commit 95ee2897e98f) 2023-08-17T13:06:29Z Bojan Novković bojan.novkovic@fer.hr 2023-05-09T07:02:04Z urn:sha1:82eece443ee3eed9a04481e7127271985734ddff This patch fixes virtual machine single stepping on VMX hosts. Currently, when using bhyve's gdb stub, each attempt at single-stepping a vCPU lands in a timer interrupt. The current single-stepping mechanism uses the Monitor Trap Flag feature to cause VMEXIT after a single instruction is executed. Unfortunately, the SDM states that MTF causes VMEXITs for the next instruction that gets executed, which is often not what the person using the debugger expects. [1] This patch adds a new VM capability that masks interrupts on a vCPU by blocking interrupt injection and modifies the gdb stub to use the newly added capability while single-stepping a vCPU. [1] Intel SDM 26.5.2 Vol. 3C Reviewed by: corvink, jbh MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D39949 (cherry picked from commit fefac543590db4e1461235b7c936f46026d0f318) 2023-07-25T15:13:49Z Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58Z urn:sha1:caa41f641755c935b036e17440a3b49329c904ed The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix (cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b) 2023-03-17T10:26:33Z Vitaliy Gusev gusev.vitaliy@gmail.com 2023-02-28T10:32:49Z urn:sha1:38acc80a5b696a0f9d029b5de209b6a2045332cd vmx_snapshot() and svm_snapshot() do not save any data and error occurs at resume: Restoring kernel structs... vm_restore_kern_struct: Kernel struct size was 0 for: vmx Failed to restore kernel structs. Reviewed by: corvink, markj Fixes: 39ec056e6dbd89e26ee21d2928dbd37335de0ebc ("vmm: Rework snapshotting of CPU-specific per-vCPU data.") MFC after: 2 weeks Sponsored by: vStack Differential Revision: https://reviews.freebsd.org/D38476 (cherry picked from commit 8104fc31a234bad1ba68910f66876395fc58ebdc) 2023-02-08T09:28:47Z Corvin Köhne corvink@FreeBSD.org 2022-11-15T10:53:49Z urn:sha1:7148611e4f560f375d4b92fdeb9451a792dc73fc 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 (cherry picked from commit 892feec2211d0dbd58252a34d78dbcb2d5dd7593) 2023-01-26T22:07:12Z John Baldwin jhb@FreeBSD.org 2022-11-30T21:06:46Z urn:sha1:d786f1706ed4c4642a6f517377f0af37693ee027 Support for rendezvous outside of a vcpu context (vcpuid of -1) was removed in commit 949f0f47a4e7, and the vm, vcpuid argument pair was replaced by a single struct vcpu pointer in commit d8be3d523dd5. Reported by: andrew (cherry picked from commit 1f6db5d6b5de5e0cafcdb141a988120b0faea049) 2023-01-26T22:06:28Z John Baldwin jhb@FreeBSD.org 2022-11-18T18:06:08Z urn:sha1:3e02f8809aec5f8c28d8ad329c0328d3ed4cc069 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 (cherry picked from commit ee98f99d7a68b284a669fefb969cbfc31df2d0ab) 2023-01-26T22:06:16Z John Baldwin jhb@FreeBSD.org 2022-11-18T18:05:35Z urn:sha1:8ff0e2a57d970fea9d009976302a07ffc49980d3 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 (cherry picked from commit 98568a005a193ce2c37702a8377ddd10c570e452) 2023-01-26T22:05:52Z John Baldwin jhb@FreeBSD.org 2022-11-18T18:05:10Z urn:sha1:b88a7eae3584c338c80611269b5790637386d798 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 (cherry picked from commit c0f35dbf19c3c8825bd2b321d8efd582807d1940)