Re: [Qemu-ppc] [PATCH|RFC 1/1] pci: allow 0 address for PCI IO/MEM regions

[Alexander Graf]

On 07/22/15 19:08, Laurent Vivier wrote:
> On 22/07/2015 18:47, Alexander Graf wrote:
> > On 07/22/15 18:17, Michael S. Tsirkin wrote:
> > > On Wed, Jul 22, 2015 at 01:54:59PM +0200, Laurent Vivier wrote:
> > > > From: Michael Roth <address@hidden>
> > > >
> > > > Some kernels program a 0 address for io regions. PCI 3.0 spec
> > > > section 6.2.5.1 doesn't seem to disallow this.
> > > >
> > > > Signed-off-by: Michael Roth <address@hidden>
> > > > [lvivier: add accept_addr_0 in PCIBus to conditionally allow addr 0,
> > > >    as this can break other architectures]
> > > > Signed-off-by: Laurent Vivier <address@hidden>
> > > I guess it's a solution - though I'd rather fix up priorities
> > > for PC and others.
> > Won't this break Linux? IIRC there was a check in Linux that declares
> > IO==0 addresses as invalid on PCI enumeration.
> Well, without this patch, it doesn't work (try 2.4.0-rcX -M pseries and
> add a virtio-net-pci card).
>
> But the address 0 appears only on PCI hotplug. The first card we add
> "lively" is always inserted with address 0 for BAR0 (even if we have
> already a PCI card on the bus).
>
> If we add a second card, it works well (as it can't have the address 0
> again).
>
> If we reboot the machine, the cards are reordered and have "valid" (!=
> 0) addresses.
>
> Do you suspect a bug in the kernel PCI hotplug functions ?

I'm not quite sure whether there is an actually visible bug, but I 
wanted to make sure you're aware that I've run into horrible issues on 
real hardware that exposed IO BARs at address 0 and then told Linux to 
not reconfigure BARs. Because then some code somewhere hidden deep 
inside Linux just assumes that the BAR is invalid.

IIRC BAR mapping for sPAPR hotplug happens in QEMU, no? So you can just 
guarantee that it never hits 0.


Alex