Date: Mon, 23 Oct 2023 21:18:25 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 274389] bhyve in 15-CURRENT unable to boot OpenBSD anymore Message-ID: <bug-274389-27103-c41Mc9Yyud@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-274389-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-274389-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274389 --- Comment #8 from John Baldwin <jhb@FreeBSD.org> --- So it's an OS bug that it's writing 0 to "disable" a BAR as that doesn't wo= rk.=20 However, bhyve crashing isn't really ideal either. For a case like this wh= ere there is a conflict, I think we should do something that isn't a crash.=20 Probably the guest OS will assign a new range in the future if it actually cares about the BAR in question. The simplest approach might be to let the "first" BAR that claims a region win and have other register attempts simply fail (but mark the BAR as "unmapped" so we don't try to unregister it in the future). This would not fix the edge case that if the first device to regi= ster the range moves its BAR (or disables decoding), the second device's BAR wou= ld not start working, instead it would remain disabled. However, given how od= d of a case this is, I'm fine with that. Note that this is just about the assertion failure, and it doesn't help with the first error reported as the original bug here which I think we still do= n't understand. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-274389-27103-c41Mc9Yyud>