Pci pmem

[krystian-hebel]

No description provided.

[macpijan]

@SergiiDmytruk Can you please take a look if you have approached this area as well when rebasing (updating) edk2?

[SergiiDmytruk]

I remember those patches, but I didn't analyze the code and reasons for them much. As I understand:

• coreboot produces state which EDK can't handle
• both old (no or very little pmem) and new code (some pmem) are workarounds for that
• new code makes if-statement in

  edk2/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c

  Lines 1955 to 1972 in 176c51d

  	//
  	// Get the Address Translation Offset
  	//
  	if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
  	Descriptor->AddrTranslationOffset = GetMmioAddressTranslationOffset (
  	PciIoDevice->PciRootBridgeIo,
  	Descriptor->AddrRangeMin,
  	Descriptor->AddrLen
  	);
  	if (Descriptor->AddrTranslationOffset == (UINT64) -1) {
  	FreePool (Descriptor);
  	return EFI_UNSUPPORTED;
  	}
  	}
  	// According to UEFI spec 2.7, we need return host address for
  	// PciIo->GetBarAttributes, and host address = device address - translation.
  	Descriptor->AddrRangeMin -= Descriptor->AddrTranslationOffset;

  
  to not execute for some region of memory in case of coreboot+EDK in Qemu, because now it remains pmem

If that's correct, then this is an improvement in a sense that things are less broken in this case :) We might want to have this coreboot<->EDK incompatibility tracked somewhere though if it's not already tracked.

[krystian-hebel]

Possibly the same thing caused https://ticket.coreboot.org/issues/415 and https://ticket.coreboot.org/issues/499. In QEMU I initially had it the other way around, CONFIG_RESOURCE_ALLOCATION_TOP_DOWN made it work fail elsewhere.