bhyve:officehours:16december2020

Table of Contents

Agenda
Video
Meeting Notes

Agenda

Intro to bhyve office hours
Notable commits in the past month
Upcoming work
Short talks
- SMR for EPT TLB shootdown
- bhyve KVM unit-test support
Q & A

Video

YouTube video of bhyve Office Hours Meeting

Meeting Notes

Notable commits in the past month
- Not a huge amount of activity in bhyve commits, as the year is winding up.
- SMR for EPT.
- Save/Restore added with support across virtiostor, ahci, virtrand and xhci.
- 64bit PCI passthrough work. Fixing some of the current limitations but further work is required to get GPU passthrough working correctly.
- UEFI Firmware. TianoCore edk2 has been used by bhyve since the implementation of UEFI. The current version is based off a 2014 snapshot with bhyve specific changes added. Over the time, it never really has been updated until recently by Rebecca Cran. Those changes have been merged into upstream to reduce the amount of work required to release newer versions based on the quarterly cadence that the TianoCore project releases at. This will allow for upstream to be directly used in ports and stay updated.

Upcoming work
- Patch set for ARMv8 support in bhyve. More ARM64 boards are now available and there is ongoing decline in the ARM32 space. A lot of work has been done by the team at Polytechnic in Bucharest. This is a large review of code to get through.
- Intel GPU passthrough. A large patch set has been submitted for review and changes a lot of areas in the bhyve code. This will take a while to move through and review.
- Fixes for the VNC client interaction with bhyve guests and performance improvements to improve end-user experience.
- VirtIO 1.1 support for guest. Not really bhyve specific but will add so guests that support 1.1 can take advantage of features offered.
- Save/restore for a single device improvement. Re-working the configuration format of JSON and separating it out of bhyve to reduce the complexity of code.

Short talks
- SMR for EPT TLB talk presented by markj@.
- Brief review of bhyve configuration work by johnb@
- bhyve KVM unit-test presented by grehen@.

Q & A
- grehen@ to markj@, how do you use bhyve?
  - Uses it to speed up development workflows. Currently used for kernel address space testing. Also used for kernel fuzzing.
  - allanjude@ uses it for ZFS development to load and unload kernel modules while working on OpenZFS code.

With 13 on the horizon what testing should consumers be doing on upcoming features and what features are coming up?
- VNC client testing is needed and verification that it is functioning correctly, existing features continue to work as they do now and that it is working better than it was before with improved performance.
- Future project to boot Linux kernels as soon as they are released. Arch a good candidate to test this going forward.

How is PCI passthrough coming along for passing through USB devices, webcams etc?
- Jitter and latency is a problem to take into consideration and is one of the major hurdles.
- Thoughts on creating a proxy USB daemon that manages USB devices then passing USB devices in and out of bhyve guests is a way to achieve this.

Is there a way to use bhyvectl to gracefully shutdown a guest?
- Complicated but doable now. Would need a bit of refinement but could be done through UNIX domain sockets.
- Sending AHCI shutdown signals to guests that support it, exists in current implementations.

Active disk resizing (increasing) without having to shutdown and start a guest?
- Could be done through UNIX domain sockets as well.

Has the iflib code for disablement of LRO on adaptors added to bridges been fixed yet?
- No.
- One way to fix would be to enable TSO and checksums for guests.
- Support soft TSO in bhyve for guests could be added?

Checksum netmap/VALE implements TSO/LRO?
- No checksumming done during packet movement.
- No LRO done in OpenBSD.
- Checksum always done on virtio packets within the OpenBSD driver.
- Currently only an OpenBSD issue and could be fixed if the implementation of virtIO net either disabled checksums like other implementations or had an option to disable it if the end-user needed it off.

Is the VMM stats accounting in good shape for increasing the vCPU count? *John’s review: https://reviews.freebsd.org/D27463

Offload support for tap interfaces ?
- Review can be found here: https://reviews.freebsd.org/D21315 at this time, there has been no feedback.