From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz3cD-00062g-Fa for qemu-devel@nongnu.org; Wed, 18 Nov 2015 09:21:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz3cA-0004il-BR for qemu-devel@nongnu.org; Wed, 18 Nov 2015 09:21:41 -0500 Date: Wed, 18 Nov 2015 16:21:32 +0200 From: "Michael S. Tsirkin" Message-ID: <20151118161859-mutt-send-email-mst@redhat.com> References: <1447201710-10229-1-git-send-email-benh@kernel.crashing.org> <1447201710-10229-45-git-send-email-benh@kernel.crashing.org> <564C6FB3.1000703@redhat.com> <564C720B.10106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564C720B.10106@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-2.5 44/77] pci-bridge: Set a supported devfn_min for bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org 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