Re: [Qemu-devel] [PATCH for-2.5 44/77] pci-bridge: Set a supported devfn_min for bridge

[Michael S. Tsirkin]

On Wed, Nov 18, 2015 at 01:41:47PM +0100, Paolo Bonzini wrote:
> On 18/11/2015 13:31, Paolo Bonzini wrote:
> > 
> > 
> > On 11/11/2015 01:27, Benjamin Herrenschmidt wrote:
> >>      if (bridge_dev->flags & (1 << PCI_BRIDGE_DEV_F_SHPC_REQ)) {
> >> +        /* SHCP gets upset if we try to use slot 0 */
> >> +        br->sec_bus.devfn_min = PCI_FUNC_MAX;
> >>          dev->config[PCI_INTERRUPT_PIN] = 0x1;
> >>          memory_region_init(&bridge_dev->bar, OBJECT(dev), "shpc-bar",
> >>                             shpc_bar_size(dev));
> > 
> > This needs backwards compatibility gunk unfortunately.  However we
> > should fix it in 2.5 because it's a bug.  I'll send a patch.
> 
> Actually it turns out that the forbidden configuration is blocked elsewhere:
> 
> $ x86_64-softmmu/qemu-system-x86_64 \
>       -device pci-bridge,id=foo,chassis_nr=1 \
>       -device virtio-scsi-pci,bus=foo
> qemu-system-x86_64: -device virtio-scsi-pci,bus=foo: Unsupported PCI
> slot 0 for standard hotplug controller. Valid slots are between 1 and 31.
> 
> so this patch is just allowing the above command line to work.  There's
> no effect with or without the patch if addr=0, so the patch is good for
> 2.5 IMO.
> 
> Michael, can you queue it?
> 
> Paolo

This depends on the devfn_min thing, right?
I'm yet to review it, generally I'd prefer to
avoid changing device allocation rules since
that makes it so easy to break compatibility.

Assuming addresses are all explicitly stated,
is there even a problem?
If not, maybe we can defer everything to after 2.5.

-- 
MST