Skip to content
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
wants to merge 8 commits into
base: dev
Choose a base branch
from
Open

Conversation

markjdb
Copy link
Contributor

@markjdb markjdb commented Jul 31, 2024

Some of these are pending review upstream so perhaps we should wait until those land so that we have clean cherry-picks from FreeBSD.

  • Fix a problem where -G w<portnum> causes the guest to abort after being resumed if more than one vCPU is configured.
  • Fix a problem where some gdb command replies were not being escaped properly, causing gdb to fail to read capabilities from memory if one is unlucky.
  • Fix a problem where u-boot triggers an assertion failure in bhyve by reprogramming BARs.

@markjdb
Copy link
Contributor Author

markjdb commented Aug 14, 2024

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 <[email protected]>
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant