From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 57CC4211E7437 for ; Fri, 22 Mar 2019 02:06:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5C323082AFC; Fri, 22 Mar 2019 09:06:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-95.rdu2.redhat.com [10.10.120.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F9F75D9CC; Fri, 22 Mar 2019 09:06:46 +0000 (UTC) To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Igor Druzhinin Cc: edk2-devel@lists.01.org, ard.biesheuvel@linaro.org, jordan.l.justen@intel.com, julien.grall@arm.com, anthony.perard@citrix.com, xen-devel@lists.xenproject.org, Ray Ni References: <1551876056-28223-1-git-send-email-igor.druzhinin@citrix.com> <1551876056-28223-2-git-send-email-igor.druzhinin@citrix.com> <20190322082650.tk65vju74g4gt7vj@MacBook-Air-de-Roger.local> From: Laszlo Ersek Message-ID: <7b8b9559-6479-9ee0-5b5a-300b43606669@redhat.com> Date: Fri, 22 Mar 2019 10:06:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190322082650.tk65vju74g4gt7vj@MacBook-Air-de-Roger.local> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Fri, 22 Mar 2019 09:06:49 +0000 (UTC) Subject: Re: [Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 09:06:50 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 03/22/19 09:33, Roger Pau Monné wrote: > On Wed, Mar 06, 2019 at 12:40:54PM +0000, Igor Druzhinin wrote: >> This aperture doesn't exist in OVMF and trying to use it causes >> failing assertions later in cases there are prefetchable and >> non-prefetchable BARs following each other. This configuration is >> quite likely with some PCI passthrough devices. > > According to the PCIe spec, it's fine to place prefetchable BARs in > non-prefetchable memory space. There's a note that says that most > implementations will only have 1G of non-prefetchable memory, and > that most scalable platforms will map 32bit BARs into > non-prefetchable memory regardless of the prefetchable bit value. > > Shouldn't OVMF be fine with finding both prefetchable and > non-prefetchable BARs, as long as the memory region is set to > non-prefetchable? > > Does OVMF have the capability to position BARs by itself? If so we > could skip of the placement done by hvmloader and just let OVMF > position things where it see fit. The core PciBusDxe driver that is built into OVMF certainly does the resource allocation/placement, but when OVMF is executed on Xen, this functionality of PciBusDxe is dynamically disabled by setting PcdPciDisableBusEnumeration to TRUE. (I'm not saying this is right vs. wrong, just that it happens.) Note that OVMF itself checks PcdPciDisableBusEnumeration for many things (just grep OvmfPkg to see), so if we were to flip the PCD while running on Xen, it would change the behavior of OVMF on Xen in a number of areas. Can't offer a deeper treatise for now; all the related source code locations would have to be audited (likely with "git blame" too). Now, if PciBusDxe *is* allowed/requested to lay out the BARs, through the PCD, then it (indirectly) depends on platform code to provide the resource apertures -- of the root bridges -- out of which it can allocate the BARs. My understanding is that XenSupport.c tries to detect these apertures "retroactively", from the pre-existing BAR placements. This was contributed by Ray in commit 49effaf26ec9 ("OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over Xen", 2016-05-11), so I'll have to defer to him on the code. I believe that, if we flipped the PCD to FALSE on Xen, and hvmloader would stop pre-configuring the BARs (or OVMF would simply ignore that pre-config), then this code (XenSupport.c) should be possible to eliminate -- *however*, in that case, some other Xen-specific code would become necessary, to expose the root bridge resource apertures (out of which BARs should be allocated by PciBusDxe, see above). In QEMU's case: all root bridges share the same apertures between each other (given any specific resource type). They are communicated via dynamic PCDs. The 32-bit MMIO aperture PCDs are set in PlatformPei somewhat simply (based on QEMU machine type, IIRC). The 64-bit MMIO aperture PCDs are also calculated in PlatformPei, but that calculation is a *lot* more complex. All in all, the "root" information is the set of apertures, i.e. what parts of the GPA space can be used for what resource allocation. Thanks, Laszlo