Revision tags: release/14.0.0 |
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
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
show more ...
|
Revision tags: release/13.2.0, release/12.4.0 |
|
#
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
|
#
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 ...
|
Revision tags: release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0 |
|
#
483d953a |
| 05-May-2020 |
John Baldwin <jhb@FreeBSD.org> |
Initial support for bhyve save and restore.
Save and restore (also known as suspend and resume) permits a snapshot to be taken of a guest's state that can later be resumed. In the current implement
Initial support for bhyve save and restore.
Save and restore (also known as suspend and resume) permits a snapshot to be taken of a guest's state that can later be resumed. In the current implementation, bhyve(8) creates a UNIX domain socket that is used by bhyvectl(8) to send a request to save a snapshot (and optionally exit after the snapshot has been taken). A snapshot currently consists of two files: the first holds a copy of guest RAM, and the second file holds other guest state such as vCPU register values and device model state.
To resume a guest, bhyve(8) must be started with a matching pair of command line arguments to instantiate the same set of device models as well as a pointer to the saved snapshot.
While the current implementation is useful for several uses cases, it has a few limitations. The file format for saving the guest state is tied to the ABI of internal bhyve structures and is not self-describing (in that it does not communicate the set of device models present in the system). In addition, the state saved for some device models closely matches the internal data structures which might prove a challenge for compatibility of snapshot files across a range of bhyve versions. The file format also does not currently support versioning of individual chunks of state. As a result, the current file format is not a fixed binary format and future revisions to save and restore will break binary compatiblity of snapshot files. The goal is to move to a more flexible format that adds versioning, etc. and at that point to commit to providing a reasonable level of compatibility. As a result, the current implementation is not enabled by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option for userland builds, and the kernel option BHYVE_SHAPSHOT.
Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz Relnotes: yes Sponsored by: University Politehnica of Bucharest Sponsored by: Matthew Grooms (student scholarships) Sponsored by: iXsystems Differential Revision: https://reviews.freebsd.org/D19495
show more ...
|
Revision tags: release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
ebc3c37c |
| 13-Jun-2018 |
Marcelo Araujo <araujo@FreeBSD.org> |
Add SPDX tags to vmm(4).
MFC after: 4 weeks. Sponsored by: iXsystems Inc.
|
#
65eefbe4 |
| 18-Jan-2018 |
John Baldwin <jhb@FreeBSD.org> |
Save and restore guest debug registers.
Currently most of the debug registers are not saved and restored during VM transitions allowing guest and host debug register values to leak into the opposite
Save and restore guest debug registers.
Currently most of the debug registers are not saved and restored during VM transitions allowing guest and host debug register values to leak into the opposite context. One result is that hardware watchpoints do not work reliably within a guest under VT-x.
Due to differences in SVM and VT-x, slightly different approaches are used.
For VT-x:
- Enable debug register save/restore for VM entry/exit in the VMCS for DR7 and MSR_DEBUGCTL. - Explicitly save DR0-3,6 of the guest. - Explicitly save DR0-3,6-7, MSR_DEBUGCTL, and the trap flag from %rflags for the host. Note that because DR6 is "software" managed and not stored in the VMCS a kernel debugger which single steps through VM entry could corrupt the guest DR6 (since a single step trap taken after loading the guest DR6 could alter the DR6 register). To avoid this, explicitly disable single-stepping via the trace flag before loading the guest DR6. A determined debugger could still defeat this by setting a breakpoint after the guest DR6 was loaded and then single-stepping.
For SVM: - Enable debug register caching in the VMCB for DR6/DR7. - Explicitly save DR0-3 of the guest. - Explicitly save DR0-3,6-7, and MSR_DEBUGCTL for the host. Since SVM saves the guest DR6 in the VMCB, the race with single-stepping described for VT-x does not exist.
For both platforms, expose all of the guest DRx values via --get-drX and --set-drX flags to bhyvectl.
Discussed with: avg, grehan Tested by: avg (SVM), myself (VT-x) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D13229
show more ...
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0 |
|
#
b5ff185e |
| 12-Sep-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from head
|
#
ab875b71 |
| 14-Aug-2015 |
Navdeep Parhar <np@FreeBSD.org> |
Catch up with head, primarily for the 1.14.4.0 firmware.
|
Revision tags: release/10.2.0 |
|
#
94f6f93a |
| 23-Jun-2015 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r284644 through r284736.
|
#
90e528f8 |
| 23-Jun-2015 |
Neel Natu <neel@FreeBSD.org> |
Restore the host's GS.base before returning from 'svm_launch()'.
Previously this was done by the caller of 'svm_launch()' after it returned. This works fine as long as no code is executed in the int
Restore the host's GS.base before returning from 'svm_launch()'.
Previously this was done by the caller of 'svm_launch()' after it returned. This works fine as long as no code is executed in the interim that depends on pcpu data.
The dtrace probe 'fbt:vmm:svm_launch:return' broke this assumption because it calls 'dtrace_probe()' which in turn relies on pcpu data.
Reported by: avg MFC after: 1 week
show more ...
|
#
8f0ea33f |
| 13-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head revisions r273096-r277147
Sponsored by: The FreeBSD Foundation
|
#
9268022b |
| 19-Nov-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head@274682
|
Revision tags: release/10.1.0 |
|
#
5c9ef378 |
| 04-Nov-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r274095.
|
#
a78dc032 |
| 21-Oct-2014 |
Neel Natu <neel@FreeBSD.org> |
Merge projects/bhyve_svm into HEAD.
After this change bhyve supports AMD processors with the SVM/AMD-V hardware extensions.
More details available here: https://lists.freebsd.org/pipermail/freebsd-
Merge projects/bhyve_svm into HEAD.
After this change bhyve supports AMD processors with the SVM/AMD-V hardware extensions.
More details available here: https://lists.freebsd.org/pipermail/freebsd-virtualization/2014-October/002905.html
Submitted by: Anish Gupta (akgupt3@gmail.com) Tested by: Benjamin Perrault (ben.perrault@gmail.com) Tested by: Willem Jan Withagen (wjw@digiware.nl)
show more ...
|
#
8fe9436d |
| 11-Oct-2014 |
Neel Natu <neel@FreeBSD.org> |
Get rid of unused headers. Restrict scope of malloc types M_SVM and M_SVM_VLAPIC by making them static. Replace ERR() with KASSERT(). style(9) cleanup.
|
#
30571674 |
| 27-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
Simplify register state save and restore across a VMRUN:
- Host registers are now stored on the stack instead of a per-cpu host context.
- Host %FS and %GS selectors are not saved and restored acro
Simplify register state save and restore across a VMRUN:
- Host registers are now stored on the stack instead of a per-cpu host context.
- Host %FS and %GS selectors are not saved and restored across VMRUN. - Restoring the %FS/%GS selectors was futile anyways since that only updates the low 32 bits of base address in the hidden descriptor state. - GS.base is properly updated via the MSR_GSBASE on return from svm_launch(). - FS.base is not used while inside the kernel so it can be safely ignored.
- Add function prologue/epilogue so svm_launch() can be traced with Dtrace's FBT entry/exit probes. They also serve to save/restore the host %rbp across VMRUN.
Reviewed by: grehan Discussed with: Anish Gupta (akgupt3@gmail.com)
show more ...
|
#
af198d88 |
| 22-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
Allow more VMCB fields to be cached: - CR2 - CR0, CR3, CR4 and EFER - GDT/IDT base/limit fields - CS/DS/ES/SS selector/base/limit/attrib fields
The caching can be further restricted via the tunable
Allow more VMCB fields to be cached: - CR2 - CR0, CR3, CR4 and EFER - GDT/IDT base/limit fields - CS/DS/ES/SS selector/base/limit/attrib fields
The caching can be further restricted via the tunable 'hw.vmm.svm.vmcb_clean'.
Restructure the code such that the fields above are only modified in a single place. This makes it easy to invalidate the VMCB cache when any of these fields is modified.
show more ...
|
Revision tags: release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0 |
|
#
b18ac2d8 |
| 27-Apr-2013 |
Neel Natu <neel@FreeBSD.org> |
- SVM nested paging support - Define data structures to contain the SVM vcpu context - Define data structures to contain guest and host software context - Change license in vmcb.h and vmcb.c to remov
- SVM nested paging support - Define data structures to contain the SVM vcpu context - Define data structures to contain guest and host software context - Change license in vmcb.h and vmcb.c to remove references to NetApp that inadvertently sneaked in when the license text was copied from amdv.c.
Submitted by: Anish Gupta (akgupt3@gmail.com)
show more ...
|