Date: Fri, 22 May 2026 22:35:07 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 36b855f18925 - main - amd64/vmm: Lock global PCI passthrough structures Message-ID: <55o37qso-91n9-8rns-s584-3o2pp736105p@serrofq.bet> In-Reply-To: <ahDYa6Y-gpvKt8ub@nuc> References: <69860b30.3f83f.acb567e@gitrepo.freebsd.org> <21416977-p363-rs27-90n6-qq2o931r4ps5@mnoonqbm.arg> <ahDYa6Y-gpvKt8ub@nuc>
index | next in thread | previous in thread | raw e-mail
On Fri, 22 May 2026, Mark Johnston wrote: >> There's a bug here. That should be return (error). That's been breaking >> pci passthru since February. I cannot imagine how no one noticed this in >> 3 months? > > Fixed in commit b13335331092, thanks. > > If I'm reading the bhyve code correctly, this is "cosmetic": the > libvmmapi wrapper for this operation is vm_unmap_pptdev_mmio(), called > in bhyve's passthru_mmio_map(). When the ioctl fails, > passthru_mmio_map() prints that warning and returns an error to the > caller... and all callers ignore it. I think that was true even before > my refactoring in commit 86150ed98b790. > > How exactly is passthru broken for you? Was goingt o say see virtualization@ but maybe it's not broken as such as I am fighting the next issue. After fixing the ENOENT locally and the errors (or warnings as you say) being gone, which I thought may be the cause preventing the next bit, I am still not getting a virtio-net device to netboot the guest. The tap interface is there and also gets connected but EFI says there is no device to boot from. I am still trying to debug that. Help will be appreciated :) -- Bjoern A. Zeeb r15:7home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55o37qso-91n9-8rns-s584-3o2pp736105p>