bump PORTREVISION

In D45049#1040000, @markj wrote:

Thank you! I think this means though that @jhb 's suggestion isn't viable, as we generally expect newer bhyve to work properly with older EDK2. In other words, we need some config flag which lets a particular platform say, "I want to enable BARs before executing any guest code". Or is there something more clever we can do?

In D45049#1039608, @markj wrote:

In D45049#1027224, @jhb wrote:

So for "bare metal" cases like booting with a bootrom (e.g. UEFI) we should arguably leave bars unregistered since the raw firmware probably does that. Only the bhyveload case probably wants to enable BARs on startup. I would be fine with not using a user-facing config option but basically making the test in this patch be some kind of "is there a bootrom or not" check. Would need to test it on amd64 with UEFI.

I implemented this and EDK2 fails to load our loader. I get the following output before dropped into a shell:

Launching virtual machine "test" ...                                                                                                                          
fbuf frame buffer base: 0x32b086e00000 [sz 33554432]                                                                                                          
BdsDxe: loading Boot0001 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)                      
BdsDxe: starting Boot0001 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)                     
UEFI Interactive Shell v2.2                                                                                                                                   
EDK II                                                                                                                                                        
UEFI v2.70 (BHYVE, 0x00010000)                                                                                                                                
map: No mapping found.

Presumably EDK2 does rely on us having registered BARs. After staring at the EDK2 bhyve platform code for a while, I'm not sure how this is encoded.

• fix style issues

• fix style issues

• fix style issues
• unmap vbt->hva in error path

• merge entries with predecessor and successor if possible

• use unsigned int
• add comment

IIRC, the default value of the busmasteren, porten and memen bits is 0 according to PCI specification. So, as jhb already mentioned, it should be valid to unset these values when booting with a bootrom.

First of all, looks good. Splitting the commit is just a suggestion!

Can this patch be split into multiple smaller ones to make it easier for review?

You have to add an entry to the manpage before we can commit it.

Not sure if it's worth parsing the header file and the pci.ids file. If you want to update the header file, you can simply parse the pci.ids file and diff the output or you simply overwrite the header file and use git clean up the diff.

You should add a manpage entry.

Already fixed by 4e288572b8581

Is this still WIP? And could it be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270966 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266325?

In D42921#978988, @jhb wrote:

I just don't understand why it's under kern.random and in the random driver? It would make sense to me for this to just be under kern and probably live in sys/kern/kern_mib.c instead with a SYSINIT to initialize it?

• firstboot handling in linprocfs is not required anymore

I'm not sure who's the right person to review this. I've found you in the git log of dev/random and linprocfs.

FYI: I've send this patch to EDKII https://edk2.groups.io/g/devel/topic/patch_v1_1_1_ovmfpkg_bhyve/102646333

• fix newline style

In D42627#972664, @manu wrote:

I'm ok with this as long as this will be upstreamed and that the patch will be dropped in a future update.

In D42627#972662, @manu wrote:

In D42627#972655, @corvink wrote:

• set EDKII IO port range to [ 0x2000, 0x10000 ] too

Did you forget a patch ? I don't see any diff between your two diffs

I do agree with jhb. Why do we need to make it optional? If there's no use case, just drop BHYVE_SLIRP. We can add it later if required.

• set EDKII IO port range to [ 0x2000, 0x10000 ] too

Maybe add some more information to the commit message. Something like "This commit adds a new capability to enable software breakpoints. When enabled, vmexits are passed to userspace where they should be handled. ..."