From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZINkw-0003bJ-BN for qemu-devel@nongnu.org; Thu, 23 Jul 2015 17:10:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZINkr-0003oc-Ii for qemu-devel@nongnu.org; Thu, 23 Jul 2015 17:10:18 -0400 Date: Fri, 24 Jul 2015 00:10:07 +0300 From: "Michael S. Tsirkin" Message-ID: <20150724000923-mutt-send-email-mst@redhat.com> References: <1437566099-10004-1-git-send-email-lvivier@redhat.com> <1437675858-14070-1-git-send-email-lvivier@redhat.com> <1437684406.7562.62.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] pci: allow 0 address for PCI IO/MEM regions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Laurent Vivier , Michael Roth , QEMU Developers , "qemu-ppc@nongnu.org" , David Gibson On Thu, Jul 23, 2015 at 10:00:30PM +0100, Peter Maydell wrote: > On 23 July 2015 at 21:46, Benjamin Herrenschmidt > wrote: > > On Thu, 2015-07-23 at 20:24 +0200, Laurent Vivier wrote: > >> From: Michael Roth > >> > >> 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 > >> [lvivier: add pci_allow_0_addr in MachineClass to conditionally > >> allow addr 0 for pseries, as this can break other architectures] > >> Signed-off-by: Laurent Vivier > >> --- > > > > Why would it break other architectures ? The PCI bus will forward > > address 0 just fine and some devices will decode it just fine too, > > regardless of the architecture they are put on. I don't see why > > having BARs capable of decoding it would break anything... > > Discussion from last time around: > http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01358.html > > suggests that it's a workaround for our PC model being buggy > and putting 0-address BARs over the top of some other system > device rather than underneath them... > > (Also, none of our PCI device models actually try to do > the "BAR at zero means I won't respond" behaviour, which > presumably they might do in real life.) > > -- PMM Maybe some devices do this, but I'm guessing not all of them, since there's no hint in the pci spec that they should. -- MST