FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F13.2.0 2023-02-09T07:54:16Z 2023-02-09T07:54:16Z Edward Tomasz Napierala trasz@FreeBSD.org 2022-01-04T13:25:12Z urn:sha1:87271de92c4a69cfe92656c16bbef467e60b8c3b This will be used to fix Linux signal delivery. Discussed With: kib Sponsored By: EPSRC (cherry picked from commit 562bc0a943d1fad1a9b551557609d2941a851b4d) 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:24Z John Baldwin jhb@FreeBSD.org 2022-12-09T18:26:23Z urn:sha1:3bedbb1008a82641b785d58f5c0def8ce5ec5377 These are manipulating state in a ppt(4) device none of which is vCPU-specific. Mark the vcpu fields in the relevant ioctl structures as unused, but don't remove them for now. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37639 (cherry picked from commit 91980db1beecd52e34a1550a247e374cfcc746a2) 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) 2023-01-26T22:05:02Z John Baldwin jhb@FreeBSD.org 2022-11-18T18:04:37Z urn:sha1:aca0d0b421d3ee7b844edf949902c0c189279ad7 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 (cherry picked from commit 67b69e76e8eecfd204f6de636d622a1d681c8d7e) 2023-01-26T22:03:29Z John Baldwin jhb@FreeBSD.org 2022-11-18T18:03:52Z urn:sha1:3348ba1d6da9fd64038770cc38f0651e6d085963 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 (cherry picked from commit 3f0f4b1598e0e7005bebed7ea3458e96d0fb8e2f) 2023-01-26T22:02:21Z John Baldwin jhb@FreeBSD.org 2022-11-18T18:03:34Z urn:sha1:67ade508ce0a64692dcf7a37b7fd3fb4dd25970e Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37165 (cherry picked from commit d8be3d523dd50a17f48957c1bb2e0cd7bbf02cab)