bhyve: add allocation function to E820

[corvink]

Summary

This function makes it easy to allocate new E820 entries. It will be
used to allocate graphics memory for Intel integrated graphic devices.

[markj]

Is there any mechanism to ensure that no new entries are added once the table is passed to fwcfg?

usr.sbin/bhyve/e820.c

343

e820_add_entry() would be a more descriptive name IMO.

369

Missing parens around return values in this function.

[corvink]

In D39547#900422, @markj wrote:

Is there any mechanism to ensure that no new entries are added once the table is passed to fwcfg?

The table isn't passed directly to the guest. e820_get_fwcfg_item converts the current table into a fwcfg item. So, changes of the table aren't reflected by the fwcfg item.

[corvink]

• rebase
• fix style issues

[corvink]

usr.sbin/bhyve/e820.c

343

e820_add_entry already exists. This function tries is a wrapper around e820_add_entry to add an entry at a specific address.

[markj]

usr.sbin/bhyve/e820.c

287

It's hard to understand what this function is doing. Is it supposed to find holes between existing entries, or does it replace existing entries of type E820_TYPE_MEMORY?

[corvink]

usr.sbin/bhyve/e820.c

287

It allocates a region in E820_TYPE_MEMORY and marks it as another memory type. So, it replaces existing E820_TYPE_MEMORY entries. E.g.:

dump_table:
  0x0000 - 0x1000 E820_TYPE_MEMORY

alloc_highest(0xFFFF, 0x0100, 0, E820_TYPE_RESERVED);

dump_table:
  0x0000 - 0x0E00 E820_TYPE_MEMORY
  0x0E00 - 0x1000 E820_TYPE_RESERVED

[markj]

usr.sbin/bhyve/e820.c

299

Why do you check that end - length != 0?

328

What's wrong with base == 0?

[corvink]

usr.sbin/bhyve/e820.c

299

Same reason as base == 0 for alloc_lowest. If end - length == 0, we'll end up allocating address 0 which should be avoided in most cases.

328

We shouldn't allocate memory at address 0. Not sure if the caller or the callee should be responsible to avoid it.

[markj]

usr.sbin/bhyve/e820.c

299

I think some brief comments would help here.