A fix for the bug #229852 (bhyve: IOMMU (Intel VTd) PCI passthrough attempt locks up some systems) was stated as MFCed 6 months ago (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229852#c21 and https://svnweb.freebsd.org/base?view=revision&revision=355440) but it's still not included in 12.1R-P5. This is a severe bug crashing the entire system (12.1R) when starting bhyve with pci passthru.
*** This bug has been marked as a duplicate of bug 229852 ***
Thank you for the report Anatoli The commit in base r349184 was indeed merged (MFC'd) to stable/12 in base r355440 (see bug 229852) Merges to *stable* branches are scheduled for inclusion in *future* minor releases. Only Errata Notices (EN's) and Security Fixes (SA's) are pushed to releng" branches, that is to say, included in "current" minor releases (*.*-pX releases) If you would like to request that the resolution for bug 229852 be considered an EN (Errata Notice), please re-open that issue. Having said that, given the date of the original fix/merge (over 6 months ago), and the schedule for future 12.x releases, an EN request is unlikely to be accepted (in my opinion, I may be wrong).
I'm reopening this bug report as suggested by Kubilay Kocak as I believe this bug (together with the #245392) is a show-stopper for production use of bhyve with pci passthru in some environments (this one on Intel CPUs, the other one with OpenBSD/NetBSD guests). #245392 was blocking PCI passthru use with other BSDs for years. In my particular case I'm deploying an infrastructure with 2 enterprise-grade servers as bhyve hosts serving dozens of OpenBSD guests and we can't use STABLE nor can we wait for 6 months more for these fixes to be included in 12.2R (we already got a considerable delay because of these bugs). Though maybe it makes sense to combine both bugs in a single EN, when #245392 gets closed.
I would like to second the request for this to be considered for an EN to 12.1-RELEASE. I spent almost half a day recently trying to figure out why passing through a NIC on one particular Xeon 12.1 host was crashing the host before I found this bug. I’d be surprised if the new Xeon systems I’ve recently ordered don’t also have the same issue. As this if for a production environment, I’d prefer not to have to run off of 12-STABLE.
I believe secteam@ is responsible for ENs.
This looks like a credible errata notice candidate. It would be helpful for secteam if someone could write up the problem in the errata notice template: https://www.freebsd.org/security/errata-template.txt We can do the copy-editing and we'll take care of merging fixes to supported release branches and issuing the errata notice.
I've made a note in secteam wip.md to track this issue for a future errata/advisory batch.
(In reply to Philip Paeps from comment #6) Thanks Philip! If no one else steps up to write an EN draft, I will spend some time on it on Monday. It would be better if someone more familiar with the bug would do it, though.
Created attachment 215307 [details] errata notice I completed the template for the EN, leaving some parts in the header and the "Correction details" sections as this is my first EN and I'm not sure how to complete them. Please note, these are 2 different bug fixes with 2 different revisions (both reflected in all the sections and revision numbers provided in the Correction details).
(In reply to Anatoli from comment #9) Thanks Anatoli! I've added your draft to the secteam repository. We'll take it from here.
(In reply to Anatoli from comment #9) The correction details refer to the final commit (i.e., if you have at least that version or at least that date, you have the full fix). The fix is these two revisions in stable/12: r355440 r361686 so r361686 is the rev we'll use for the correction details. Unfortunately these two commits do not apply cleanly to releng/12.1, so additional work will be necessary.
(In reply to Ed Maste from comment #11) > so r361686 is the rev we'll use for the correction details. OK, got it. > Unfortunately these two commits do not apply cleanly to releng/12.1, so additional work will be necessary. Which of the 2 commits doesn't apply cleanly? If it's the r361686 one, we'd need to /cc Peter Grehan.
The conflicts can simply resolve with a merge/accept yours.
(In reply to Ed Maste from comment #11) Hi Ed, Does the suggestion by Peter solves the issue with the two commits not applying cleanly?
Ed/Philip - anything else that needs to be done here ? Would it help if I supplied a diff ?
I think we can include this in our next batch of errata/advisories. I think we have everything we need. The merge looks straightforward. Thank you!
Hi, Just wanted to confirm the fixes will be included in 12.1R-p7 and also would like to ask when it's expected to be released? There's a mention about these fixes in the the about to be published 2020q2 freebsd-quarterly [1] and it would be great to have the fixes released in p7 before the freebsd-quarterly is published. Thanks, Anatoli [1] https://github.com/freebsd/freebsd-quarterly/blob/master/2020q2/bhyve-intel-openbsd.md
Author: gordon Date: Wed Jul 8 19:56:34 2020 New Revision: 363022 URL: https://svnweb.freebsd.org/changeset/base/363022 Log: Fix host crash in bhyve with PCI device passthrough. Approved by: so Security: FreeBSD-EN-20:13.bhyve Modified: releng/12.1/sys/amd64/vmm/intel/vtd.c releng/12.1/usr.sbin/bhyve/pci_emul.c releng/12.1/usr.sbin/bhyve/pci_emul.h releng/12.1/usr.sbin/bhyve/pci_passthru.c