In D46562#1064622, @rosenfeld_grumpf.hope-2000.org wrote:

Do I need a more elaborate commit message here, too?

Also, and in general, where do testing notes go, assuming they are needed?

Where's the commit message?

It would be a very good idea to improve your commit message. It would be nice to explain the use case in more detail (if possible). Additionally, it would be great to mention limitations of this new feature e.g. that user have to make sure to protect the tcp socket from unprivileged access.

ping

ping

ping

ping

ping

Please add a commit message.

Is this ready? So far, LGTM.

In D46402#1059143, @mp wrote:

@corvink thank you for the reviews. Hopefully these last changes should address all of your feedback.

LGTM. Will test it.

• avoid code duplication by moving the code below element insertion

• use a new top level case to detect empty entries

@markj @jhb Any feedback?

What's CID: 1521334?

In D46196#1053211, @jhb wrote:

Hmm, I guess I'm not sure why the vCPU would already be in the debug_cpus set if it hasn't done anything yet? This would seem like a bug where we suspended a vCPU that wasn't in vcpus_active yet?

Shouldn't we set the command register to a known good value or do we expect that the host always sets a good value? If the host disables mem/io decoding for some reason, we're unable to read any values from the BARs MMIO space.

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