Can we keep the CSM one until the bitter end, and build it from the existing repo ?

In D27230#607935, @grehan wrote:

Can we keep the CSM one until the bitter end, and build it from the existing repo ?

Yes! That's a good idea, since I know people do still want CSM functionality.

I've also updated the name/version fields of the uefi-edk2-bhyve port to be:

PORTNAME=	uefi-edk2-bhyve
DISTVERSIONPREFIX=	edk2-stable
DISTVERSION=	202011
PORTEPOCH=	1

The DISTVERSION is for the upcoming edk2-stable202011 tag that's being created next week.
I restored PORTEPOCH to ensure that this new version will upgrade older 0.2 installations.

Oh I also bumped the PORTEPOCH to 2 to make sure the new version of g20201129 is considered greater than the previous 0.2.

Thanks Ben!

The CSM port shouldn't really default to a debug build, but I can fix that in a later change since it's existing behavior.

I've had a report that Windows 10 crashes (bugchecks) with this firmware, so I need to do more testing (on FreeBSD 11, 12 and 13-CURRENT) before committing it.

I've uploaded new binaries to https://people.freebsd.org/~bcran/bhyve/BhyveX64-20201213/ .

On my system this EFI version will fail, if a 64-bit BAR above 4 GB is used. GCD-Memory doesn't covers the MMIO-Space above 4 GB:

InitRootBridge: populated root bus 0, with room for 0 subordinate bus(es)
RootBridge: PciRoot(0x0)
  Support/Attr: 7001F / 7001F
    DmaAbove4G: No
NoExtConfSpace: Yes
     AllocAttr: 0 ()
           Bus: 0 - 0 Translation=0
            Io: 2000 - 20BF Translation=0
           Mem: C0000000 - C1FFFFFF Translation=0
    MemAbove4G: 4000000000 - 400FFFFFFF Translation=0
          PMem: FFFFFFFFFFFFFFFF - 0 Translation=0
   PMemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0

GCDMemType Range                             Capabilities     Attributes
========== ================================= ================ ================
SystemMem  0000000000000000-000000000009FFFF 800000000002600F 0000000000000000*
MMIO       00000000000A0000-00000000000FFFFF C700000000026001 0000000000000000
SystemMem  0000000000100000-000000003EFFFFFF 800000000002600F 0000000000000000*
SystemMem  000000003F000000-000000003F1FFFFF 800000000002600F 0000000000020000*
SystemMem  000000003F200000-000000003FBBEFFF 800000000002600F 0000000000000000*
SystemMem  000000003FBBF000-000000003FBBFFFF 800000000002600F 0000000000004000*
SystemMem  000000003FBC0000-000000003FBC2FFF 800000000002600F 0000000000020000*
SystemMem  000000003FBC3000-000000003FBC5FFF 800000000002600F 0000000000004000*
SystemMem  000000003FBC6000-000000003FBC8FFF 800000000002600F 0000000000020000*
SystemMem  000000003FBC9000-000000003FBCAFFF 800000000002600F 0000000000004000*
SystemMem  000000003FBCB000-000000003FBFFFFF 800000000002600F 0000000000000000*
SystemMem  000000003FC00000-000000003FDFFFFF 800000000002600F 0000000000020000*
SystemMem  000000003FE00000-000000003FFFFFFF 800000000002600F 0000000000000000*
NonExist   0000000040000000-000000007FFFFFFF 0000000000000000 0000000000000000
MMIO       0000000080000000-00000000BFFFFFFF C700000000026001 0000000000000000
MMIO       00000000C0000000-00000000C1FFFFFF C700000000026001 0000000000000000*
MMIO       00000000C2000000-00000000FBFFFFFF C700000000026001 0000000000000000
NonExist   00000000FC000000-00000000FEBFFFFF 0000000000000000 0000000000000000
MMIO       00000000FEC00000-00000000FEC00FFF C700000000026001 0000000000000000
NonExist   00000000FEC01000-00000000FECFFFFF 0000000000000000 0000000000000000
MMIO       00000000FED00000-00000000FED003FF C700000000000001 0000000000000000
NonExist   00000000FED00400-00000000FEDFFFFF 0000000000000000 0000000000000000
MMIO       00000000FEE00000-00000000FEE00FFF C700000000026001 0000000000000000*
MMIO       00000000FEE01000-00000000FEEFFFFF C700000000026001 0000000000000000
NonExist   00000000FEF00000-0000000FFFFFFFFF 0000000000000000 0000000000000000


ASSERT_EFI_ERROR (Status = Not Found)
ASSERT [PciHostBridgeDxe] /usr/ports/sysutils/uefi-edk2-bhyve/work/edk2-d4633b36b94f7b4a1f41901657cbbff452173d35/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(332): !EFI_ERROR (CheckStatus)

GCD ends at 0x10 0000 0000 which is smaller than MemAbove4G (0x40 0000 0000). A possible solution could be to patch GetFirstNonAddress located in OvmfPkg/Bhyve/PlatformPei/MemDetect.c:

EDIT: Enabling Bus Enumeration fixes this issue too.

In D27230#617382, @c.koehne_beckhoff.com wrote:

EDIT: Enabling Bus Enumeration fixes this issue too.

Thanks, I'm testing enabling bus enumeration now, and will submit a patch upstream.

Apologies for being absent recently - life took over... but I’ll have some time to look at this again between Xmas and New Year.

In D27230#616878, @bcran wrote:

I've had a report that Windows 10 crashes (bugchecks) with this firmware, so I need to do more testing (on FreeBSD 11, 12 and 13-CURRENT) before committing it.

Any progress fixing this? Would you like to commit the update using one revision older from upstream that didn’t have this issue?

In D27230#619596, @woodsb02 wrote:

Apologies for being absent recently - life took over... but I’ll have some time to look at this again between Xmas and New Year.

In D27230#616878, @bcran wrote:

I've had a report that Windows 10 crashes (bugchecks) with this firmware, so I need to do more testing (on FreeBSD 11, 12 and 13-CURRENT) before committing it.

Any progress fixing this? Would you like to commit the update using one revision older from upstream that didn’t have this issue?

I'm just getting back to it now. I'm currently working on the MemAbove4G issue, but I did run Windows 10 and it appears to work, but ended up hanging. I need to check if it's also a problem with old firmware.

I successfully installed and ran Windows 10 with the new firmware today.
So I think the last remaining issue will be the MemAbove4G problem.

@c.koehne_beckhoff.com
I see what's going wrong, and have reproduced the issue on my Threadripper system.
EDK2 firmware configures the maximum address based on the size of guest memory, with a minimum of 64GB (36 bits).
But the PCI code in bhyve puts the BAR at (highest host CPU address / 4) - meaning that on my system it puts it at 64TB.

Unless someone else is working on it, I think the solution would be to update the bhyve hypervisor to put the BAR somewhere relatively close above guest RAM. For example on a 16GB guest, KVM on Linux puts it at 32GB.

UEFI is configuring an address size less than that which the host CPU supports, because (cc @grehan) :

//
// As guest-physical memory size grows, the permanent PEI RAM requirements
// are dominated by the identity-mapping page tables built by the DXE IPL.
// The DXL IPL keys off of the physical address bits advertized in the CPU
// HOB. To conserve memory, we calculate the minimum address width here.
  
//
// The minimum address width is 36 (covers up to and excluding 64 GB, which
// is the maximum for Ia32 + PAE). The theoretical architecture maximum for
// X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits. We
// can simply assert that here, since 48 bits are good enough for 256 TB.
//

GCD map depends on gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base and gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size which are set at OvmfPkg/Bhyve/PlatformPei/MemDetect.c (GetFirstNonAddress):

BhyveX64.dsc:

gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000

MemDetect.c (GetFirstNonAddress):

FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
Pci64Size = PcdGet64 (PcdPciMmio64Size);
Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
Pci64Size = ALIGN_VALUE (Pci64Size, (UINT64)SIZE_1GB);
Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size));

//
// The core PciHostBridgeDxe driver will automatically add this range to
// the GCD memory space map through our PciHostBridgeLib instance; here we
// only need to set the PCDs.
//
PcdStatus = PcdSet64S (PcdPciMmio64Base, Pci64Base);
PcdStatus = PcdSet64S (PcdPciMmio64Size, Pci64Size);

gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base is set to guest RAM size and it's aligned on a 32 GB boundary (gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size == 0x800000000 == 32 GB).

I could create a patch for bhyve hypervisor to put 64 bit BARs on next 32 GB boundary behind guest RAM.

At this point, I'd like to get this committed as soon as possible so we can move away from gcc 4.8 and python 2.

I'm not a ports committer so can't really review the ports part, but I think moving the non-CSM ROM to the newer one seems fine. I think grehan@ has also already signed off on this?

In D27230#642824, @jhb wrote:

I'm not a ports committer so can't really review the ports part, but I think moving the non-CSM ROM to the newer one seems fine. I think grehan@ has also already signed off on this?

Thanks. Yes, Peter signed off on it via Slack.

The 64-bit issue is still present in the updated EDK2 (and being worked on), but moving off python2/gcc48 is a more pressing issue.

Committed as r565866.