Date: Sat, 31 Oct 2020 16:40:49 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 250580] VMware UEFI guests crash in virtual hardware after r366691 Message-ID: <bug-250580-227-Kiw6MvDyFa@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-250580-227@https.bugs.freebsd.org/bugzilla/> References: <bug-250580-227@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=3D250580 --- Comment #4 from Phillip R. Jaenke <prj@rootwyrm.com> --- (In reply to Roger Leigh from comment #3) Yep, confirmed now this is not AMD-specific. Reproduced on a BabyDragon Gen= .5 and a BabyDragon Gen.3. Looking over things more closely, I am far more confident that imp@'s fix f= or bhyve is what broke VMware. I think the PCI probe is what's causing it. However, that makes it an open-ended question of is it FreeBSD at fault or = is it VMware at fault? If VMware's response is malformed, well, boom. But if FreeBSD's probe is malformed, also boom. We need to get a VMware engineer involved here to sort it out. I think we're running afoul of assumptions about behavior made on both sides. FreeBSD ass= umed where a video device would be previously, and assumed a reasonable response= to a probe, while VMware may have assumed FreeBSD wouldn't probe the video dev= ice, and may not be answering in a sane fashion. --=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-250580-227-Kiw6MvDyFa>