Quoting Peter Maydell (2013-12-05 17:33:48) > On 5 December 2013 22:33, Michael Roth <mdr...@linux.vnet.ibm.com> wrote: > > Some kernels program a 0 address for io regions. PCI 3.0 spec > > sectio 6.2.5.1 doesn't seem to disallow this. > > Hmm. The last PCI spec I looked at said 0 wasn't a valid MMIO > address, so the variant of this patch I wrote a while back made it > a per PCI device flag whether a particular device let you get away > with it: > http://patchwork.ozlabs.org/patch/269133/ > > (the device in question for me was the versatile-pci host bridge). > > And presumably whoever put that specific check for 0 into > QEMU had a reason for it. > > On the other hand I can't now find whatever document it was > that I was reading that claimed 0 wasn't valid :-(
Can't seem to find anything either, checked the 2.3 spec as well. I tried to look up the git history for the new_addr == 0 check but unfortunately it seemed to be part of the initial check-in. The only clue I've found regarding special-casing for a 0-bar is this: "Power-up software can determine how much address space the device requires by writing a value of all 1's to the register and then reading the value back. The device will return 0's in all don't-care address bits, effectively specifying the address space required. Unimplemented Base Address registers are hardwired to zero." - PCI 3.0, 6.2.5.1 But that's only applicable in cases where we're sizing the bar. However, the way things are implemented in pci_bar_address(), update hooks for unimplemented/zero-sized bars as well as zero-address bars would be handled by the same code, so I wonder if that was initially added to check the former? It's a bit of a stretch, since QEMU sets the reported sizes and not the guest, but maybe? Does that seem familiar wrt the documentation you mentioned, or was it something else? > > thanks > -- PMM
