Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

["Laszlo Ersek" <lersek@redhat.com>]

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 <jordan.l.justen@intel.com>
>> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> 
> 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