Quoting Claudio Fontana (2015-01-09 08:57:39) > Hello, > > resurrecting an old thread.. I incurred in the same issue being > discussed before, > where QEMU silently ignores PCI BAR address programming attempts where > the I/O space offset is 0 (zero). > > I think that from a QEMU "user" standpoint, beside this particular issue, > which can be easily worked around just using a minimum offset, > it would be good if QEMU would be a bit verbose in producing a warning > about this. > > I think that at least it would be worth a message if DEBUG_PCI is set. > > This silent discarding of BAR programming attempts has been painful > while doing early enablement > even for other cases (like the requirement to set I/O space bit before > hand etc), which are legitimate, > but are still worthy of a diagnostic I think, at the very least if > doing pci enablement (which to me translates in having DEBUG_PCI set). > > What do you guys think, would a patch be welcome trying to address that? > Would you make the diagnostic dependent on DEBUG_PCI?
I've sent an updated patch (which allows 0-address MEM regions as well) as a separate patchset. My hope is that we can simply allow the programming of 0-address mem/io bars, but there are some concerns I still don't quite understand but have attempted to summarize to continue the discussion: http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg03453.html Debugging would be useful, but there are undoubtedly cases where the current behavior prevents proper initialization of guest devices on existing guests which expect 0 to be valid, so at the very least I think we should allow the behavior to be enabled on a machine/host-bridge level of granularity, if not for all machines/host-bridges as the patch above does. > > Thanks, > > Claudio