On Wed, 8 Oct 2025 at 20:21, Navid Emamdoost <[email protected]> wrote: > > The qpci_iomap() function fails with a fatal g_assert(addr) if it > probes a PCI BAR that has a size of zero. This is expected behavior > for certain devices, like the Q35 PCI Host Bridge, which have valid but > unimplemented BARs. > This assertion blocks the creation of fuzz targets for complex machine > types that include these devices. > Make the check conditional on !CONFIG_FUZZ. In fuzzing builds, a > zero-sized BAR is now handled gracefully by returning an empty BAR > struct, allowing fuzzing to proceed. The original assertion is kept for > all other builds to maintain strict checking for qtest and production > environments. > > Signed-off-by: Navid Emamdoost <[email protected]> > --- > tests/qtest/libqos/pci.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/tests/qtest/libqos/pci.c b/tests/qtest/libqos/pci.c > index a59197b992..df9e2a3993 100644 > --- a/tests/qtest/libqos/pci.c > +++ b/tests/qtest/libqos/pci.c > @@ -541,6 +541,22 @@ QPCIBar qpci_iomap(QPCIDevice *dev, int barno, uint64_t > *sizeptr) > addr &= PCI_BASE_ADDRESS_MEM_MASK; > } > > +#ifdef CONFIG_FUZZ > + /* > + * During fuzzing runs, an unimplemented BAR (addr=0) is not a fatal > + * error. This occurs when probing devices like the Q35 host bridge. We > + * return gracefully to allow fuzzing to continue. In non-fuzzing builds, > + * we retain the original g_assert() to catch unexpected behavior. > + */ > + if (!addr) { > + if (sizeptr) { > + *sizeptr = 0; > + } > + memset(&bar, 0, sizeof(bar)); > + return bar; > + } > +#endif
Personally I think I'd prefer it if we didn't make this dependent on CONFIG_FUZZ. If BARs with no size are a valid thing then the libqos API should handle them (e.g. in theory one should be able to write a test that the Q35 host bridge provides the addr=0 BARs it is supposed to). I think if we added the size to the QPCIBar struct then we could assert in the accessors like qpci_io_readb() and friends that the offset provided was in range. That would catch both the unlikely "we implemented the BAR with no size" case and the rather more likely "we got the size too small" case (and also the "bug in the test and it got the offset too big" case), and would mean that we don't lose anything by not asserting that we have a non-zero-size BAR here. What do you think? thanks -- PMM
