aboutsummaryrefslogtreecommitdiff
path: root/sys/amd64/include
Commit message (Collapse)AuthorAgeFilesLines
...
* vmm: Avoid embedding cpuset_t ioctl ABIsMark Johnston2023-05-242-4/+11
| | | | | | | | | | | | | | | | | | | | | | | Commit 0bda8d3e9f7a ("vmm: permit some IPIs to be handled by userspace") embedded cpuset_t into the vmm(4) ioctl ABI. This was a mistake since we otherwise have some leeway to change the cpuset_t for the whole system, but we want to keep the vmm ioctl ABI stable. Rework IPI reporting to avoid this problem. Along the way, make VM_RUN a bit more efficient: - Split vmexit metadata out of the main VM_RUN structure. This data is only written by the kernel. - Have userspace pass a cpuset_t pointer and cpusetsize in the VM_RUN structure, as is done for cpuset syscalls. - Have the destination CPU mask for VM_EXITCODE_IPIs live outside the vmexit info structure, and make VM_RUN copy it out separately. Zero out any extra bytes in the CPU mask, like cpuset syscalls do. - Modify the vmexit handler prototype to take a full VM_RUN structure. PR: 271330 Reviewed by: corvink, jhb (previous versions) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D40113
* spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDWarner Losh2023-05-1224-24/+24
| | | | | | | | | 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
* amd64: pmap.h put a guard around a pcpu.h functionBjoern A. Zeeb2023-05-121-0/+2
| | | | | | | | | | pmap_get_pcid() calls zpcpu_get() which is defined in pcpu.h. It is unclear why we do not include that header but like right above the change add another guard around pmap_get_pcid(). This allows some LinuxKPI headers to compile again. Suggested by: markj MFC after: 10 days
* bhyve: fix vCPU single-stepping on VMXBojan Novković2023-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | 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
* hwpmc: use kstack_contains()Mitchell Horne2023-05-061-5/+3
| | | | | | | | | | | | | | This existing helper function is preferable to the hand-rolled calculation of the kstack bounds. Make some small style improvements while here. Notably, rename every instance of "r", the return address, to "ra". Tidy the includes in the affected files. Reviewed by: jkoshy MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39909
* pmap_{un}map_io_transient: Use bool instead of boolean_t.John Baldwin2023-05-041-2/+2
| | | | | Reviewed by: imp, kib Differential Revision: https://reviews.freebsd.org/D39920
* amd64: store pcids pmap data in pcpu zoneKonstantin Belousov2023-05-022-3/+9
| | | | | | | | | | | | | This change eliminates the struct pmap_pcid array embedded into struct pmap and sized by MAXCPU, which would bloat with MAXCPU increase. Also it removes false sharing of cache lines, since the array elements are mostly locally accessed by corresponding CPUs. Suggested by: mjg Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D39890
* amd64: add pmap_get_pcid() helperKonstantin Belousov2023-05-021-0/+8
| | | | | | | Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D39890
* amd64: move definition of the struct pmap_pcids into _pmap.hKonstantin Belousov2023-05-022-6/+41
| | | | | | | | | and rename the structure to pmap_pcid. Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D39890
* x86: Move i386 timerreg.h to x86Dmitry Chagin2023-04-201-56/+0
| | | | | | Reviewed by: emaste, jhb Differential Revision: https://reviews.freebsd.org/D39656 MFC after: 1 month
* x86: Move i386 ppireg.h to x86Dmitry Chagin2023-04-201-51/+0
| | | | | Differential Revision: https://reviews.freebsd.org/D39655 MFC after: 1 month
* amd64: fix PKRU and swapout interactionKonstantin Belousov2023-04-141-0/+1
| | | | | | | | | | | | | | | | When vm_map_remove() is called from vm_swapout_map_deactivate_pages() due to swapout, PKRU attributes for the removed range must be kept intact. Provide a variant of pmap_remove(), pmap_map_delete(), to allow pmap to distinguish between real removes of the UVA mappings and any other internal removes, e.g. swapout. For non-amd64, pmap_map_delete() is stubbed by define to pmap_remove(). Reported by: andrew Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D39556
* xen/intr: introduce dev/xen/bus/intr-internal.hJulien Grall2023-04-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the xenisrc structure which needs to be shared between the core Xen interrupt code and architecture-dependent code into a separate header. A similar situation exists for the NR_EVENT_CHANNELS constant. Turn xi_intsrc into a type definition named xi_arch to reflect the new purpose of being an architectural variable for the interrupt source. This was originally implemented by Julien Grall, but has been heavily modified. The core side was renamed "intr-internal.h" and is #include'd by "arch-intr.h" instead of the other way around. This allows the architecture to add function definitions which use struct xenisrc. The original version only moved xi_intsrc into xen_arch_isrc_t. Moving xi_vector was done by the submitter. The submitter had also moved xi_activehi and xi_edgetrigger into xen_arch_isrc_t. Those disappeared with the removal of PVHv1 support. Copyright note. The current xenisrc structure was introduced at 76acc41fb7c7 by Justin T. Gibbs. Traces remain, but the strength of Copyright claims from before 2013 seem pretty weak. Reviewed by: royger Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>, 2021-03-17 19:09:01 Original implementation: Julien Grall <julien@xen.org>, 2015-10-20 09:14:56 Differential Revision: https://reviews.freebsd.org/D30648 [royger] - Adjust some line lengths - Fix comment about NR_EVENT_CHANNELS after movement. - Use #include instead of symlinks.
* xen: remove CONFIG_XEN_COMPAT, purge Xen 3.0 compatibilityElliott Mitchell2023-04-141-55/+3
| | | | | | | | | This overlaps the purpose of __XEN_INTERFACE_VERSION__. Remove Xen 3.0.2 compatibility. __XEN_INTERFACE_VERSION__ has compatibility to Xen 3.2.8 enabled. As Xen 3.3 was released almost 15 years ago, it seems unlikely anyone hasn't updated. Reviewed by: royger
* xen: switch to using core atomics for synchronizationElliott Mitchell2023-03-291-129/+0
| | | | | | | | | | | | | | Now that the atomic macros are always genuinely atomic on x86, they can be used for synchronization with Xen. A single core VM isn't too unusual, but actual single core hardware is uncommon. Replace an open-coding of evtchn_clear_port() with the inline. Substantially inspired by work done by Julien Grall <julien@xen.org>, 2014-01-13 17:40:58. Reviewed by: royger MFC after: 1 week
* bhyve: Remove vmctx member from struct vm_snapshot_meta.John Baldwin2023-03-241-23/+0
| | | | | | | | | | | | | | | | | | This is a userland-only pointer that isn't relevant to the kernel and doesn't belong in the ioctl structure shared between userland and the kernel. For the kernel, the old structure for the ioctl is still supported under COMPAT_FREEBSD13. This changes vm_snapshot_req() in libvmmapi to accept an explicit vmctx argument. It also changes vm_snapshot_guest2host_addr to take an explicit vmctx argument. As part of this change, move the declaration for this function and its wrapper macro from vmm_snapshot.h to snapshot.h as it is a userland-only API. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D38125
* libvmmapi: Add a struct vcpu and use it in most APIs.John Baldwin2023-03-242-49/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* bhyve: fix restore of kernel structsVitaliy Gusev2023-02-282-4/+1
| | | | | | | | | | | | | | | 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
* Move kstack_contains() and GET_STACK_USAGE() to MD machine/stack.hKonstantin Belousov2023-02-012-9/+24
| | | | | | | Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D38320
* vmm: avoid spurious rendezvousCorvin Köhne2023-02-011-4/+10
| | | | | | | | | | | | | | | | | | | | | | 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
* vm: centralize VM_BATCHQUEUE_SIZE definitionAndrew Gallatin2023-01-211-6/+0
| | | | | | | | | | | Remove the platform-specific definitions of VM_BATCHQUEUE_SIZE for amd64 and powerpc64, and instead treat all 64-bit platforms identically. This has the effect of increasing the arm64 and riscv VM_BATCHQUEUE_SIZE to match that of other platforms. Reviewed by: jhb, markj Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D37707
* amd64 pmap.h: make it easier to use the header for other consumersKonstantin Belousov2023-01-051-0/+2
| | | | | | | | | Guard pmap_invlpg() definition with checks that only provide it when both sys/pcpu.h and machine/cpufunc.h were already included. Requested by: Elliott Mitchell Sponsored by: The FreeBSD Foundation MFC after: 1 week
* amd64: be more precise when enabling the AlderLake small core PCID workaroundKonstantin Belousov2023-01-051-0/+1
| | | | | | | | | | | In particular, do not enable the workaround if INVPCID is not supported by the core. Reported by: "Chen, Alvin W" <Weike.Chen@Dell.com> Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D37940
* amd64: for small cores, use (big hammer) INVPCID_CTXGLOB instead of INVLPGKonstantin Belousov2022-12-312-1/+22
| | | | | | | | | | | | | | | A hypothetical CPU bug makes invalidation of global PTEs using INVLPG in pcid mode unreliable, it seems. The workaround is applied for all CPUs with small cores, since we do not know the scope of the issue, and the right fix. Reviewed by: alc (previous version) Discussed with: emaste, markj Tested by: karels PR: 261169, 266145 Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D37770
* amd64: identify small coresKonstantin Belousov2022-12-311-1/+2
| | | | | | | Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D37770
* vm: reduce lock contention when processing vm batchqueuesAndrew Gallatin2022-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | Rather than waiting until the batchqueue is full to acquire the lock & process the queue, we now start trying to acquire the lock using trylocks when the batchqueue is 1/2 full. This removes almost all contention on the vm pagequeue mutex for for our busy sendfile() based web workload. It also greadly reduces the amount of time a network driver ithread remains blocked on a mutex, and eliminates some packet drops under heavy load. So that the system does not loose the benefit of processing large batchqueues, I've doubled the size of the batchqueues. This way, when there is no contention, we process the same batch size as before. This has been run for several months on a busy Netflix server, as well as on my personal desktop. Reviewed by: markj Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D37305
* vmm: Don't lock a vCPU for VM_PPTDEV_MSI[X].John Baldwin2022-12-091-2/+2
| | | | | | | | | 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
* vmm: Remove stale comment for vm_rendezvous.John Baldwin2022-11-301-3/+0
| | | | | | | | 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
* vmm: Restore the correct vm_inject_*() prototypesMark Johnston2022-11-181-8/+8
| | | | | | Fixes: 80cb5d845b8f ("vmm: Pass vcpu instead of vm and vcpuid...") Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D37443
* vmm: Convert VM_MAXCPU into a loader tunable hw.vmm.maxcpu.John Baldwin2022-11-181-4/+2
| | | | | | | | 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
* vmm: Allocate vCPUs on first use of a vCPU.John Baldwin2022-11-181-0/+4
| | | | | | | | | | | | | | | | | 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
* vmm: Use a cpuset_t for vCPUs waiting for STARTUP IPIs.John Baldwin2022-11-181-0/+3
| | | | | | | | | | | | | | | 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
* vmm: Use an sx lock to protect the memory map.John Baldwin2022-11-181-0/+3
| | | | | | | | | | | | | | 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
* vmm: Lookup vcpu pointers in vmmdev_ioctl.John Baldwin2022-11-181-15/+14
| | | | | | | | | | | 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
* vmm: Use struct vcpu in the rendezvous code.John Baldwin2022-11-181-2/+2
| | | | | Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37165
* vmm: Pass vcpu instead of vm and vcpuid to APIs used from CPU backends.John Baldwin2022-11-181-30/+28
| | | | | Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37162
* vmm: Use struct vcpu in the instruction emulation code.John Baldwin2022-11-182-19/+64
| | | | | | | | | | | | | | | 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
* vmm: Add vm_gpa_hold_global wrapper function.John Baldwin2022-11-181-0/+2
| | | | | | | | | | 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
* bhyve: Remove unused vm and vcpu arguments from vm_copy routines.John Baldwin2022-11-181-6/+3
| | | | | | | | 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
* vmm: Use struct vcpu with the vmm_stat API.John Baldwin2022-11-181-1/+1
| | | | | | | The function callbacks still use struct vm and and vCPU index. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D37157
* vmm: Expose struct vcpu as an opaque type.John Baldwin2022-11-181-1/+6
| | | | | | | | | | | 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
* vmm: Remove the per-vm cookie argument from vmmops taking a vcpu.John Baldwin2022-11-181-17/+12
| | | | | | | | | | | 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
* vmm: Refactor storage of CPU-dependent per-vCPU data.John Baldwin2022-11-181-10/+14
| | | | | | | | | | | | | | | 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
* vmm: Rework snapshotting of CPU-specific per-vCPU data.John Baldwin2022-11-181-2/+2
| | | | | | | | | | | 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
* bhyve: Drop volatile qualifiers from snapshot codeMark Johnston2022-11-111-5/+5
| | | | | | | | | They accomplish nothing since the qualifier is casted away in calls to memcpy() and copyin()/copyout(). No functional change intended. MFC after: 2 weeks Reviewed by: corvink, jhb Differential Revision: https://reviews.freebsd.org/D37292
* vmm: permit some IPIs to be handled by userspaceCorvin Köhne2022-10-141-0/+8
| | | | | | | | | | | Add VM_EXITCODE_IPI to permit returning unhandled IPIs to userland. INIT and STARTUP IPIs are now returned to userland. Due to backward compatibility reasons, a new capability is added for enabling VM_EXITCODE_IPI. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D35623 Sponsored by: Beckhoff Automation GmbH & Co. KG
* sys: Consolidate common implementation details of PV entries.John Baldwin2022-10-071-36/+1
| | | | | | | | | | | | | | | | | Add a <sys/_pv_entry.h> intended for use in <machine/pmap.h> to define struct pv_entry, pv_chunk, and related macros and inline functions. Note that powerpc does not yet use this as while the mmu_radix pmap in powerpc uses the new scheme (albeit with fewer PV entries in a chunk than normal due to an used pv_pmap field in struct pv_entry), the Book-E pmaps for powerpc use the older style PV entries without chunks (and thus require the pv_pmap field). Suggested by: kib Reviewed by: kib Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D36685
* pmap_unmapdev/bios: Accept a pointer instead of a vm_offset_t.John Baldwin2022-09-221-1/+1
| | | | | | | | This matches the return type of pmap_mapdev/bios. Reviewed by: kib, markj Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D36548
* Revert "vmm: permit some IPIs to be handled by userspace"Emmanuel Vadot2022-09-091-8/+0
| | | | | | | | This reverts commit a5a918b7a906eaa88e0833eac70a15989d535b02. This cause some problem with vm using bhyveload. Reported by: pho, kp
* vmm: permit some IPIs to be handled by userspaceCorvin Köhne2022-09-071-0/+8
| | | | | | | | | | | Add VM_EXITCODE_IPI to permit returning unhandled IPIs to userland. INIT and Startup IPIs are now returned to userland. Due to backward compatibility reasons, a new capability is added for enabling VM_EXITCODE_IPI. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D35623 Sponsored by: Beckhoff Automation GmbH & Co. KG
generated by cgit v1.3 (git 2.53.0) at 2026-03-29 04:06:45 +0000