-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assorted bhyve bug fixes #2163
Open
markjdb
wants to merge
8
commits into
CTSRD-CHERI:dev
Choose a base branch
from
markjdb:dev-gdb-fixes
base: dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Assorted bhyve bug fixes #2163
+135
−54
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Re-did the PR with upstream cherry-picks. Two patches, https://reviews.freebsd.org/D45049 and https://reviews.freebsd.org/D46282 haven't landed upstream yet. They can arrive in a separate PR if necessary though. |
When the gdb stub is configured to pause guest execution upon boot (i.e., the "w" flag is passed to -G), vCPUs end up suspended in two senses: first, suspended by the GDB stub (marked in the vcpus_suspended set), and suspended by the kernel (because fbsdrun_addcpu() suspends APs before spawning their vCPU threads). When the guest is resumed by the debugger, vCPUs are unsuspended in both senses, but this is not correct for APs. Hack around this problem by re-suspending vCPUs after the debugger resumes guest execution, if they were suspended beforehand. Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D46196 (cherry picked from commit a9e4753b4fe20d81263f61c4b7e4383739924898)
Per https://sourceware.org/gdb/current/onlinedocs/gdb.html/Overview.html#Binary-Data certain bytes must be escaped. The XML register definitions we have so far do not run afoul of that rule, but the stub should handle them anyway. Reviewed by: jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D46194 (cherry picked from commit b4fb947923b566a3a8a6ad8e5f8ea8dec0c68ee4)
As on amd64, APs will repeatedly exit until they are brought online, so this hack helps avoid burning CPU time during guest bootup. Reviewed by: jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D46195 (cherry picked from commit 2e2b8afa52da6e2cd08482bcd512e016aa264ddb)
- In vmexit_smccc(), copy an assertion from amd64. - In fbsdrun_addcpu(), make sure that our vm_suspend_cpu() call is succesful. Reviewed by: jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D46197 (cherry picked from commit 4c5188bbeb88362112fa2891ccb6330f4c429ff3)
- On amd64, deprecate lpc.bootrom and lpc.bootvars. Use top-level config variables instead. - Introduce a generic predicate which can be used to determine whether the guest has a boot ROM. Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D46282 (cherry picked from commit 43caa2e805c28a236e6624aedd91591d7018fce5)
Let the boot ROM handle BAR initialization. This fixes a problem where u-boot's BAR remapping conflicts with some limitations in bhyve. See https://lists.freebsd.org/archives/freebsd-virtualization/2024-April/002103.html for a description of what goes wrong. The old behaviour can be restored by setting the pci.enable_bars configuration variable. Reviewed by: corvink, jhb Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D45049 (cherry picked from commit e962b37bf0ffe7f30f5b025b46ea49ba01c71f2f)
Reported by: Andy Fiddaman <andy@omniosce.org> Fixes: e962b37bf0ff ("bhyve: Do not enable PCI BAR decoding if a boot ROM is present") (cherry picked from commit 7cfdb02a73df33d33952119c87f3e12f12778360)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of these are pending review upstream so perhaps we should wait until those land so that we have clean cherry-picks from FreeBSD.
-G w<portnum>
causes the guest to abort after being resumed if more than one vCPU is configured.