- User Since
- May 9 2014, 11:24 PM (447 w, 10 h)
Sep 19 2022
Jun 13 2022
Change the MOVED entry and add a section to UPDATING.
Jun 6 2022
Add ONLY_FOR_ARCH lines and revert i386 addition at top
Add separate qemu_x64 and qemu_i386 flavors.
Jun 5 2022
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.
May 26 2022
May 25 2022
Updated sysutils/bhyve-firmware to depend on edk2@bhyve
May 21 2022
May 16 2022
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.
May 15 2022
Deleted sysutils/uefi-edk2-bhyve and added an entry to MOVED.
May 9 2022
May 8 2022
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.
Apr 25 2022
Dec 21 2021
Could I get approval from a port committer for this please?
Dec 12 2021
Keep PORTEPOCH at 2.
Is it valid to reset PORTEPOCH to 1 when updating the PORTVERSION?
Dec 5 2021
Remove romfile_dup. Fix strdup/strsep.
Dec 1 2021
Put allocations on one line.
Removed gpa variable, and used gpa_alloctop instead.
Nov 28 2021
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.
Oct 21 2021
Oct 17 2021
Jul 20 2021
Jul 7 2021
Jul 5 2021
Jul 3 2021
May 31 2021
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.
May 11 2021
May 2 2021
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.
Apr 9 2021
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".
Mar 28 2021
Mar 24 2021
@manu Sorry, could you re-approve the change please?
Mar 20 2021
We'll also need to update the port revision.
Mar 16 2021
@woodsb02 Could you review and approve this for me, please?
Mar 14 2021
Feb 18 2021
Now the firmware work has been committed, I'll switch back to working on this.
Committed as r565866.
Feb 16 2021
Feb 15 2021
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.
Jan 16 2021
The patch no longer applies against 13-CURRENT: I needed to apply several lines manually.
This works for me. I was seeing an assert failure in pci_emul.c, but it disappeared for some reason.
One person on Slack said they'd like the BAR in a fixed (high) location, so I wouldn't be confident committing this without other people (e.g. @jhb and @grehan ) reviewing it too.
Jan 5 2021
OVMF puts it at the next 16GB boundary, which might be better.
Dec 28 2020
Also, /boot/boot1.efifat is no longer included in -CURRENT.
/boot/boot1.efifat is the 800 KB filesystem image. /boot/boot1.efi is the EFI bootloader application.
Dec 26 2020
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.
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.
Dec 24 2020
I successfully installed and ran Windows 10 with the new firmware today.
So I think the last remaining issue will be the MemAbove4G problem.
Dec 23 2020
The patch no longer applies cleanly: I had to make some changes.
But after that, I was able to run Ubuntu 20.10 with gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration set to TRUE and FALSE with the following command line, which uses both rfb and passthru:
bhyve -AH -s 0:0,hostbridge -s 31:0,lpc -c 1 -m 16G -l bootrom,BHYVE_CODE.fd -l com1,stdio -s 3:0,ahci-hd,bhyve-ubuntu-20_10.img -s 7,ahci-cd, -s 8,virtio-rnd -s 6,virtio-net,tap0 -s 9,fbuf,rfb=10.0.10.117:5900,w=1920,h=1200 -s 10,xhci,tablet -s 11,passthru,24/0/0 -S guest
This was fixed in rS359719, so I think this review should be closed.
Dec 22 2020
Dec 14 2020
I've uploaded new binaries to https://people.freebsd.org/~bcran/bhyve/BhyveX64-20201213/ .
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.