From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 19 Jun 2019 15:10:22 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3C292306E5FA; Wed, 19 Jun 2019 22:10:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-91.ams2.redhat.com [10.36.116.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id 099CE5D71B; Wed, 19 Jun 2019 22:10:20 +0000 (UTC) Subject: Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM To: David Woodhouse , "devel@edk2.groups.io" Cc: Ruiyu Ni , Jordan Justen , Ard Biesheuvel References: <1463609573-16626-1-git-send-email-lersek@redhat.com> <9c690717587ff1ccd9a8ec8bd3d741e6c86f8bb3.camel@infradead.org> From: "Laszlo Ersek" Message-ID: <01a87fee-5a17-d027-39fd-2a2e0a36787b@redhat.com> Date: Thu, 20 Jun 2019 00:10:20 +0200 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: <9c690717587ff1ccd9a8ec8bd3d741e6c86f8bb3.camel@infradead.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Wed, 19 Jun 2019 22:10:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi David, On 06/19/19 14:50, David Woodhouse wrote: > On Thu, 2016-05-19 at 00:12 +0200, Laszlo Ersek wrote: >> According to edk2 commit >> >> "MdeModulePkg/PciBus: do not improperly degrade resource" >> >> and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the >> Platform Init 1.4a specification, a platform can provide such a protocol >> in order to influence the PCI resource allocation performed by the PCI Bus >> driver. >> >> In particular it is possible instruct the PCI Bus driver, with a >> "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit >> address space, regardless of whether the device features an option ROM. >> >> (By default, the PCI Bus driver considers an option ROM reason enough for >> allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if >> BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS >> binary from a combined option ROM could be dispatched, and fail to access >> MMIO BARs in 64-bit address space.) >> >> In platform code we can ascertain whether a CSM is present or not. If not, >> then legacy BIOS binaries in option ROMs can't be dispatched, hence the >> BAR degradation is detrimental, and we should prevent it. This is expected >> to conserve the 32-bit address space for 32-bit MMIO BARs. >> >> The driver added in this patch could be simplified based on the following >> facts: >> >> - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence >> the driver will exit immediately. Therefore the driver could be omitted >> from the Ia32 build. >> >> - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE >> was defined (because in that case the degradation would be justified). >> On the other hand, if CSM_ENABLE was undefined, then the driver could be >> included, and it could provide the hint unconditionally (without looking >> for the Legacy BIOS protocol). >> >> These short-cuts are not taken because they would increase the differences >> between the OVMF DSC/FDF files. If we can manage without extreme >> complexity, we should use dynamic logic (vs. build time configuration), >> plus keep conditional compilation to a minimum. >> >> Cc: Jordan Justen >> Cc: Ruiyu Ni >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Laszlo Ersek > > This (commit 855743f717745) appears not to be working any more. I see > NVMe controllers' BARs being assigned above 4GiB where the CSM can't > reach them. the driver is thoroughly commented. See especially the DriverInitialize() function. Can you determine which one(s) of those statements doesn't / don't hold any longer? Or maybe IncompatiblePciDeviceSupportDxe works as before, but commit 065ae7d717f9 ("MdeModulePkg/PciBusDxe: make OPROM BAR degradation configurable", 2016-09-26) made a difference? (Adding Ard.) I'm just guessing of course; a bisection could prove more effective. Thanks Laszlo