Date: Fri, 6 Sep 2024 11:12:43 -0400 From: Mark Johnston <markj@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Shawn Webb <shawn.webb@hardenedbsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: e962b37bf0ff - main - bhyve: Do not enable PCI BAR decoding if a boot ROM is present Message-ID: <Ztsb68pW9fCmCpZ5@nuc> In-Reply-To: <7213e551-6be2-44b1-a8b6-55645c593c12@FreeBSD.org> References: <202408191359.47JDxAbK026029@gitrepo.freebsd.org> <qkp2zbmykgwsbrxekut35rexlktypzg5oj2bbfslig7eksprpi@2lw5x47mtytp> <7213e551-6be2-44b1-a8b6-55645c593c12@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 06, 2024 at 09:37:45AM -0400, John Baldwin wrote: > On 9/5/24 22:10, Shawn Webb wrote: > > Hey Mark, > > > > This commit seems to force me to now pass "-o pci.enable_bars=true" to > > all my VMs on amd64. I wonder if that might be a POLA violation. I > > didn't realize that I needed to set that until I bisected the src > > tree, looking for the commit that broke bhyve for me. > > > > Is changing the default here really worth it for amd64? If so, I'm > > thinking this should be in both RELNOTES and UPDATING. I now have to > > propigate re-enabling this across my entire infrastructure. > > > > Thanks, > > That should only be true if you are using an older UEFI firmware that did > not program BARs. Are you seeing this on stock FreeBSD, and which version > of the UEFI ROM are you using? Indeed, it'd be nice to see which bootcode and guest you're using. I had tested bhyveload, edk2-bhyve and grub2-bhyve with this change without problems, and wasn't planning to MFC. My hope was that this wouldn't have any user-visible impact on amd64, but if that's not the case, the default for pci.enable_bars may have to be flipped on amd64.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Ztsb68pW9fCmCpZ5>