From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=162.221.156.55; helo=smtp03.citrix.com; envelope-from=prvs=980c94f35=igor.druzhinin@citrix.com; receiver=edk2-devel@lists.01.org Received: from SMTP03.CITRIX.COM (smtp03.citrix.com [162.221.156.55]) (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 06CD421A1349F for ; Mon, 25 Mar 2019 07:32:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208";a="81727963" To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Laszlo Ersek CC: , , , , , , 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> <7b8b9559-6479-9ee0-5b5a-300b43606669@redhat.com> <20190324035053.xs3yccnpmn5dy6cl@MacBook-Air-de-Roger.local> From: Igor Druzhinin Message-ID: <27273980-eab8-e1a3-b03a-8a6c75f3e05c@citrix.com> Date: Mon, 25 Mar 2019 14:32:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190324035053.xs3yccnpmn5dy6cl@MacBook-Air-de-Roger.local> 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: Mon, 25 Mar 2019 14:32:47 -0000 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit On 24/03/2019 03:50, Roger Pau Monné wrote: > On Fri, Mar 22, 2019 at 10:06:45AM +0100, Laszlo Ersek wrote: >> 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 for the detailed explanation. IMO it would be better to let > OVMF do the BAR placement instead of having to do it in hvmloader, > this just causes code duplication between projects and there's nothing > Xen-specific about the PCI resource allocation. > > I will try to find some time to look into this, albeit I'm not going > to be able to work in this immediately. I'm more than happy if someone > else has spare time and wants to pick this up. I was thinking about that as well since most of the issues I found stem from the fact hvmloader does its own things behind OVMF's back. But decided that for now it'd be better to have a quick relief than try to change the approach drastically as Laszlo pointed out there are many implications of that change. So for this patch I prefer to stick to removing only prefetchable aperture all together (as dead code) and marking the host bridge as not supporting it (as Laszlo suggested) since it reflects the reality and done similarly for QEMU-KVM. More code removals and changes could be done later. Igor