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.jus...@intel.com>
>> Cc: Ruiyu Ni <ruiyu...@intel.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <ler...@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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#42601): https://edk2.groups.io/g/devel/message/42601
Mute This Topic: https://groups.io/mt/32122513/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
