From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9bVB-0003y9-Nr for qemu-devel@nongnu.org; Fri, 09 Jan 2015 10:29:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9bV7-0006Gg-RY for qemu-devel@nongnu.org; Fri, 09 Jan 2015 10:29:29 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:36887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9bV7-0006GC-Kf for qemu-devel@nongnu.org; Fri, 09 Jan 2015 10:29:25 -0500 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Jan 2015 08:29:23 -0700 Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 90E6F6E804F for ; Fri, 9 Jan 2015 10:21:14 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t09FTLAW28770426 for ; Fri, 9 Jan 2015 15:29:21 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t09FTKEU026842 for ; Fri, 9 Jan 2015 10:29:21 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: References: Message-ID: <20150109152919.22996.30407@loki> Date: Fri, 09 Jan 2015 09:29:19 -0600 Subject: Re: [Qemu-devel] [PATCH 08/12] pci: allow 0 address for PCI IO regions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Claudio Fontana , peter.maydell@linaro.org Cc: QEMU Developers , agraf@suse.de, mst@redhat.com Quoting Claudio Fontana (2015-01-09 08:57:39) > Hello, > = > resurrecting an old thread.. I incurred in the same issue being > discussed before, > where QEMU silently ignores PCI BAR address programming attempts where > the I/O space offset is 0 (zero). > = > I think that from a QEMU "user" standpoint, beside this particular issue, > which can be easily worked around just using a minimum offset, > it would be good if QEMU would be a bit verbose in producing a warning > about this. > = > I think that at least it would be worth a message if DEBUG_PCI is set. > = > This silent discarding of BAR programming attempts has been painful > while doing early enablement > even for other cases (like the requirement to set I/O space bit before > hand etc), which are legitimate, > but are still worthy of a diagnostic I think, at the very least if > doing pci enablement (which to me translates in having DEBUG_PCI set). > = > What do you guys think, would a patch be welcome trying to address that? > Would you make the diagnostic dependent on DEBUG_PCI? I've sent an updated patch (which allows 0-address MEM regions as well) as a separate patchset. My hope is that we can simply allow the programming of 0-address mem/io bars, but there are some concerns I still don't quite understand but have attempted to summarize to continue the discussion: http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg03453.html Debugging would be useful, but there are undoubtedly cases where the current behavior prevents proper initialization of guest devices on existing guests which expect 0 to be valid, so at the very least I think we should allow the behavior to be enabled on a machine/host-bridge level of granularity, if not for all machines/host-bridges as the patch above does. > = > Thanks, > = > Claudio