In D60181#1380980, @michaelo wrote:

I am fine with that. Others should have a look as well. Do you plan to MFC it to 15?

• Mention the sysutils/swtpm port.
• Refer to the UEFI examples on VARS file creation.

Do not cache sector size, fetch it directly in cb_diskioctl()

cb_diskioctl: report the actual sector size

cb_exit(NULL, 1) -> cb_exit(NULL, USERBOOT_EXIT_QUIT)

Re-implement to make cb_getc() exit on EOF in input read().

ping?

ping?

Update the final manual pages bits.

Do not report VM PID in --get-all.

• Do not call nvlist_destroy() on NULL.
• Update vm_pid_request() to properly set report_error depending on whether it's --get-all or --get-vm-pid option.
• bhyvectl.8: rundir: s/checkpoint socket/bhyve IPC socket/.

Fix option order in the manpage.

In D59226#1358565, @markj wrote:

Does running bhyveload ... </dev/null not provide the desired behaviour?

Re-implement using IPC.

Updated the commit metadata with all the relevant fields.

Add an UPDATING entry.

In D59108#1355951, @bnovkov wrote:

This is a good feature, but I don't think that this is the correct approach design-wise. Adding an ioctl handler to just to fetch a VM's PID is overkill IMO, new ioctl commands should only be added when there's no other way to obtain the needed information (e.g., fetching memsegs and other metadata that is stored in the vmm module).

I strongly suggest that you implement this functionality using bhyve's IPC facilities. These were only reserved for the snapshot subsystem up until very recently, but I had to split these out into a separate subsystem as a part of my hotplugging work.
This should make the implementation way simpler since you just need to register an IPC handler instead of adding a new ioctl.
I just committed the refactor so you can build on top of it.

In D59080#1355723, @chuck wrote:

Thanks for finding this and fixing it.

In D59080#1354973, @markj wrote:

I'm not very familiar with nvme, but I presume this might cause problems in existing VM images that embed this identifer somewhere?

Re-implement monitoring using a pipe.

In D58788#1348937, @bnovkov wrote:

In D58788#1348916, @markj wrote:

Thanks, I've run into this problem too.

Rather than forwarding signals, why not have a pipe shared between the two processes? The child process can use it to detect when the parent goes away, and exit automatically. That should be simpler and will work for all cases where the parent exits (assertion failure, SIGKILL, etc.).

+1 for this approach, it's more robust than forwarding signals. I was planning to implement this pipe-based fix soon, but if you have the time and will to do so please go for it!

manpages ping

In D58419#1340678, @chuck wrote:

I like the approach of defining the options in each module (e.g., machdep), but it would be interesting to see what this approach looks like for one of the storage devices (e.g., NVMe) which have both their own options as well as the common blockif options.

Support module-based options sets.

@bcr @ziaee could you possibly take a look?