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

[Laurent Vivier]

On 23/07/2015 09:15, Alexander Graf wrote:
> 
> 
>> Am 23.07.2015 um 06:01 schrieb David Gibson <address@hidden>:
>>
>>> On Wed, Jul 22, 2015 at 07:17:16PM +0200, Alexander Graf wrote:
>>>> 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.
>>
>> It should happen in qemu, but it doesn't, yet.  
>>
>> For boot-time devices, BAR allocation is done in SLOF, even though bus
>> enumeration is done in qemu, and qemu does have code to publish
>> assigned-addresses if anything had set them.
>>
>> For hotplugged devices, the code is currently relying on some weird
>> behaviour in Linux guests that causes them to fall back to assigning
>> BARs themselves, even though they shouldn't under PAPR.  It's the
>> guest itself attempting to assign address 0 and failing.
> 
> So Linux itself tries to assign a bar to address 0? That sounds incredibly 
> odd. What code exactly does this? Is it generic or papr specific?

I guess it can happen somewhere inside this file:
drivers/pci/hotplug/ibmphp_pci.c

I'm going to try to know what really happen before going further...

Laurent