In D47202#1076215, @imp wrote:

All good. Do you need someone to push the change? Or do you still have a valid bit?

In D47202#1076166, @imp wrote:

The increased memory is trivial. Why not 128 if there's one with 63 now?

Actually update the value to 256.

Increase array size to 256, as suggested by the developer who root caused the problem.

@imp, @andrew, @jhb - I was wondering if one of you could commit this please?

I've just applied the latest version of this patch but it's still looking for aarch64/Makefile.inc both during a "make buildworld" and a "make" in usr.sbin/bhyve on my Ampere system:

bcran@gluon:~/src/freebsd/usr.sbin/bhyve % make
make: "/home/bcran/src/freebsd/usr.sbin/bhyve/Makefile" line 68: Could not find aarch64/Makefile.inc
make: Fatal errors encountered -- cannot continue
make: stopped in /home/bcran/src/freebsd/usr.sbin/bhyve

The change to usr.sbin/Makefile.aarch64 no longer applies following commit 773606fcdfae00a3f850bcd39969a63d9a8fb129.
I'm probably missing something since I'm just catching up with this work, but 'make buildworld' fails in usr.sbin/bhyve:

===> usr.sbin/bhyve (includes)
make[4]: "/home/bcran/src/usr.sbin/bhyve/Makefile" line 68: Could not find aarch64/Makefile.inc
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /home/bcran/src/usr.sbin/bhyve

In D35419#803280, @bapt wrote:

this will at best not work, it might even break some of the tools which are using MOVED

Change the MOVED entry and add a section to UPDATING.

Add ONLY_FOR_ARCH lines and revert i386 addition at top

Add separate qemu_x64 and qemu_i386 flavors.

I'm not sure how to handle the fact that qemu (OVMF) firmware can be built for both x86_64 and i386.
The existing port uses FLAVOR, but since sysutils/edk2 already uses FLAVOR for the platform, I'm not sure how selecting the architecture should be done.

Fix summary.

In D35321#800709, @gerald wrote:

Hi Rebecca, changes like this don't need review. It's best to commit them as quickly as possible since otherwise make index is broken.

Committed in https://cgit.freebsd.org/ports/commit/?id=2e6a6ccd15d1c2b83ea238325b9feddff4f8eaa7

Updated sysutils/bhyve-firmware to depend on edk2@bhyve

In D35053#799648, @gerald wrote:

Hi Rebecca, intuitively this look good and you being our resident expert - do you want to go ahead and commit this?

Urgh, I remembered just in time about sysutils/bhyve-firmware that will also need updated.

Added entry to MOVED.

Actually deleted sysutils/uefi-edk2-bhyve this time.

In D35148#797304, @manu wrote:

You probably need a CONFLICT too for this flavor this you install links at the place of the other port.

Deleted sysutils/uefi-edk2-bhyve and added an entry to MOVED.

Fixed Makefile

As I mentioned in the summary, the following code doesn't do what I want it to: it doesn't create /usr/local/share/uefi-firmware.

Keep USE_GCC

Could I get approval from a port committer for this please?

Keep PORTEPOCH at 2.

Is it valid to reset PORTEPOCH to 1 when updating the PORTVERSION?

Remove romfile_dup. Fix strdup/strsep.

Put allocations on one line.
Added {}.
Removed gpa variable, and used gpa_alloctop instead.

man page updates.

Fix romfile[,varfile] in man page.

Add back checks for var_size and total_size.

Fix tabs vs spaces.

Update code to work against FreeBSD-CURRENT.

I tested the code from https://github.com/FreeBSD-UPB/freebsd-src/tree/projects/bhyvearm64/ (as of 2021-05-29) on my SolidRun Honeycomb system and it fails to allocate resources in the gicv3 code when I run kldload vmm.

With examples like Apple's "goto fail" bug (https://www.imperialviolet.org/2014/02/22/applebug.html) I'm surprised style(9) only allows, and doesn't recommend or mandate braces around single-line statements.

I noticed this is against the svn repo:

Repository rS FreeBSD src repository - subversion"

You'll probably want to switch over to Git and rebase this patch.

Just a comment typo: "number of contained objecct handles" - should be "object".

@manu Sorry, could you re-approve the change please?

In D29254#656248, @manu wrote:

OK I see. Well for now just have a build time dep is better then.
Go ahead and commit this.

We'll also need to update the port revision.

In D29254#655711, @manu wrote:

Is the 4.8 version required for something ? Otherwise depending on lang/gcc would be better (not really sure if we have some way to do that).

@woodsb02 Could you review and approve this for me, please?

Now the firmware work has been committed, I'll switch back to working on this.

Committed as r565866.

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?

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.

Updated to code from today's master, 2021-02-14.

The patch no longer applies against 13-CURRENT: I needed to apply several lines manually.