• Rebase on 14.0-CURRENT
• Add new cmdline option to add fwcfg files specified by the user

• Rebase on 14.0-CURRENT

In D26209#788649, @wanpengqian_gmail.com wrote:

I got a intel Xe DG1 dedicated graphics adapter. I will try it later.

• don't set addr = 0 in case block

In D34465#784879, @andy_omniosce.org wrote:

In illumos, it is split up into two phases, one that parses and one that does the smbios build. This means that the keys and values show up with -o config.dump=1, which I think is useful as it provides a template for editing.
Have you considered doing something like that here?

• Rebase on 14.0-CURRENT

• make processor and memdevice strings unconfigurable

I've mainly decided to make all values configurable to avoid a special handling for single values. Additionally, I don't know if just serial_number makes sense. There's system.serial_number, board.serial_number, chassis.serial_number, ... What about using " " for unmodifiable nodes? e.g.

struct smbios_string smbios_type1_strings[] = {
	{ " ", "FreeBSD" },			/* manufacturer string */
	{ " ", "BHYVE" },			/* product string */
	{ " ", "1.0" },				/* version string */
	{ "system.serial_number", "None" },	/* serial number string */
	{ " ", "None" },			/* sku string */
	{ " ", "Virtual Machine" },		/* family string */
	{ 0 }
};

• keep old variable names to make the diff smaller

I'm going to send this patch to EDKII next week if no one complains.

• Rebase on 14.0-CURRENT

• Rebase on 14.0-CURRENT

GPU passthrough for deciated AMD GPUs will be enabled by D33129.

This patch is ready to be merged. Any comments on it?

• Rebase on 14.0-CURRENT

Can this be merged?

• do not leak varfd in bootrom_loadrom

• check if lpc.bootrom exists before calling bootrom_loadrom

• rebase on main
• check for romfile/varfile == NULL

• rebase on main
• start sentences on new line in bhyve_config
• check lpc class and subclass

• check if lpc.bootrom is NULL before strdup it

• do not strdup varfile
• remove const from romfile

• rebase on 14.0-CURRENT
• add bhyve_config entry
• fail hard if mapping the ROM fails

@jhb @markj Any suggestions on which config nodes to use for romfile and varsfile? D31578 depends on that decision.

• fix style

• fix type of MTRR offset
• handle writes to reserved fields

• rebase on CURRENT

• add base and mask register for variable ranges

In D33728#762550, @bz wrote:

Sorry for that breakage and thanks for the fix; do you mind if I commit it straight away so I can MFC the proper version?

This patch unconditionally calls init_msix_table. This breaks passthru for devices which only support MSI. I created a patch for it D33728

I have to detect intel_graphics_stolen_base and intel_graphics_stolen_size for GPU passthrough to work properly (see D26209). Instead of duplicating the code of pci_early_quirks.c, I'm reusing these variables. Since one of my devices has this missing device id, GPU passthrough doesn't work on that device.

@kib @bwidawsk @imp I added you as reviewer because I saw you've added the original file.

• use asserts for checking the return code of register_inout

In D33496#757249, @markj wrote:

Sorry if I missed it, but is there another diff to add alternate handlers for these I/O ports?

In D33433#756746, @jhb wrote:

I would perhaps avoid converting "lpc.bootrom" to a new node and instead leave it as-is for the path to the boot ROM and just add a new "lpc.bootvars" or "lpc.nvram" or some such that holds the path to the vars file.

• start every sentence on a new line in manpages
• do not convert "lpc.bootrom" into a node
• only query one nvlist variable at the same time

This patch should be updated. @jhb I could do it for you if you like to.

• rebase on 14.0-CURRENT

• fix formatting

Address feedback

In D32903#750510, @wanpengqian_gmail.com wrote:

Thank you!

The standard about timestamp is very hard to understand. I am not sure I am doing the right thing...

• fix style
• use fstat to detect romfile size
• use mmap to read romfile
• add error checking for passthru_addr_rom

In D33011#749534, @markj wrote:

I don't really like this interface. The name is too general and the interface is kind of simplistic, for example because it can only describe a single contiguous memory region and can't refer to different instances of a device. I'm not what a better interface would look like, I haven't yet read more of the patch series. But I think this deserves some more thought.

prettify code style