Page MenuHomeFreeBSD

bhyve/riscv userspace part
ClosedPublic

Authored by br on Jun 6 2024, 1:07 PM.
Tags
None
Referenced Files
F106212200: D45512.diff
Fri, Dec 27, 6:40 AM
Unknown Object (File)
Sat, Dec 21, 5:38 PM
Unknown Object (File)
Wed, Dec 11, 8:49 AM
Unknown Object (File)
Sat, Dec 7, 12:57 AM
Unknown Object (File)
Fri, Dec 6, 6:31 PM
Unknown Object (File)
Fri, Dec 6, 6:31 PM
Unknown Object (File)
Fri, Dec 6, 6:30 PM
Unknown Object (File)
Fri, Dec 6, 6:30 PM
Subscribers

Details

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.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

br requested review of this revision.Jun 6 2024, 1:07 PM

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.

  • handle SBI in userspace
  • add a break statement into switch (based on markj@ comment)
usr.sbin/bhyve/riscv/fdt.c
98

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.

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
usr.sbin/bhyve/riscv/fdt.c
98

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

add vmexit_hyp for exceptions that could not be handled

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?

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 marked 9 inline comments as done.

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 marked an inline comment as done.

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

This revision was not accepted when it landed; it landed in state Needs Review.Oct 31 2024, 8:26 PM
This revision was automatically updated to reflect the committed changes.