bhyve/riscv userspace part

[br]

Summary

relatively small part compare to upcoming kernel patch.
needed to run bhyve and bhyvectl on riscv

Test Plan

Tested on single-core, single guest VM instance.

[markj]

This looks fine to me. I don't really like the duplication of fdt.c, but it's not that much code and it's not obvious to me that creating a generic FDT layer is useful at this point.

usr.sbin/bhyve/riscv/vmexit.c

153

Formally, there should be a break here.

[br]

• handle SBI in userspace
• add a break statement into switch (based on markj@ comment)

[br]

Regenerate

[br]

SMP support added

[jrtc27]

usr.sbin/bhyve/riscv/fdt.c

98

• H isn't supported for the guest
• Zicntr and Zihpm are implied by I in riscv,isa; see https://github.com/torvalds/linux/blob/4f5e249ec0ea8872e1644df23cffffbe28007188/Documentation/devicetree/bindings/riscv/extensions.yaml#L43-L45

Also, do you actually trap and emulate Sstc on systems that lack it?

usr.sbin/bhyve/riscv/vmexit.c

62

This needs to be initialised to set the BSP.

182

>=? Though I don't love how we're conflating the vcpu number and the hart ID. In practice making them the same is probably sensible, but it might be nice to decouple the two, with no-op conversion functions.

[br]

addressing @jrtc27 comments

• Fix isa string for the guest in DTS
• set bootable CPU bit into running_cpumask
• add no-op CPU_TO_HART / HART_TO_CPU macroses

[br]

usr.sbin/bhyve/riscv/fdt.c

98

ok.
No we currently don't emulate SSTC, so we require it in HW for VMM.ko

[br]

Regenerate

[br]

add vmexit_hyp for exceptions that could not be handled

[br]

Regenerate

[markj]

usr.sbin/bhyve/riscv/vmexit.c

61

Is this really correct? Unrelated __FreeBSD_version bumps will change the SBI version. I'm not sure if that's desirable.

191

If you change this to return (-1);, you can get rid of ret.

But, the return value is ignored entirely.

274

This return value is ignored. Should we report an error somewhere or log it or something?

[mhorne]

usr.sbin/bhyve/riscv/bhyverun_machdep.c

61–63

This is probably always fine, but it seems it could be placed dynamically after the bootrom, and whatever else is loaded into highmem.

usr.sbin/bhyve/riscv/vmexit.c

61

It is returned in the "implementation version" call, and is therefore implementation defined and not generally used; this is distinct from the version of the SBI specification that is implemented (currently 0.2).

This does open a window where the guest can query the exact patch-level of the host's bhyve(8) utility.

251–252

It would be better to provide a macro near the top of the file than doing this inline; it highlights our targeted spec compliance.

[br]

Address comments

usr.sbin/bhyve/riscv/vmexit.c

191

It's a bit more complicated as we are returning status code in the A0 register.
I have converted the function to return void. thanks!

251–252

Added. Thanks!

274

I fixed this to return void. Ret is written into a A0 register as result code

[br]

Instead of using static address for device tree blob, locate it just after bootrom image dynamically.

[br]

Regenerate