virtualbox: default access method, C vCPU count

[Wenzel]

Refs #312 (libmicrovmi part; the LibVMI fork pins this branch's head).

Summary

The VirtualBox Driver gets a default Access method, ADR-0004 superseding ADR-0003's no-default rule:

init_virtualbox(params)
  MachineDebugger            -> MachineDebugger, never falls back
  VBoxVMI { Some(path) }     -> VBoxVMI at path, never falls back
  VBoxVMI { None }           -> VBoxVMI at default socket, never falls back
  None (default)             -> socket = vboxapi::vmi_socket_path(vm_name)
                                  VBoxVMI(socket) ok           -> VBoxVMI     (info log)
                                  Connect error, ENOENT        -> MachineDebugger (info log, reason)
                                  any other error (busy, ...)  -> error

• Default socket: VBoxInternal/VMI/SocketPath extradata, else <IVirtualBox::HomeFolder>/vmi/<IMachine::Id>.sock, the same as ConsoleImplConfigCommon.cpp. It comes from new vboxapi::vmi_socket_path (Wenzel/rs-vboxapi@fcd2e49). So the default, and VBoxVMI without a path, need both methods (virtualbox feature):
  • virtualbox-vmi only: they fail with VBoxVmiSocketPathRequired
  • virtualbox-api only: the default is MachineDebugger
• C ABI layout is unchanged:
  • access_method = 0 means the default
  • VBOX_ACCESS_METHOD_VBOXVMI with a null socket_path means the default socket
  • new bool microvmi_get_vcpu_count(void*, uint16_t*)
• Rust: VBoxInitParams::VBoxVMI::socket_path: Option<String>.
• Python: virtualbox left unset means the default, and VBoxInitParamsPy.VBoxVMI() means the default socket. The Volatility URL handler no longer requires vbox_access_method.
• Harness: VBOX_TEST_METHOD=default|default-fallback and the test virtualbox_default_method_selection.

Evidence

Run against the patched VirtualBox (vmi/cross-method-test build) on microvmi-alpine, with RUST_LOG=microvmi=info:

VBOX_TEST_METHOD=default           virtualbox_default_method_selection ... ok
  INFO VirtualBox: VBoxVMI access method, socket ".../vbox-home/vmi/e69a20af-....sock"
  (second default init while the socket is busy -> "already connected" error, no fallback)
VBOX_TEST_METHOD=default-fallback  virtualbox_default_method_selection ... ok
  INFO VirtualBox: MachineDebugger access method, falling back: no VBoxVMI socket ".../e69a20af-....sock"
  (explicit VBoxVMI without a path -> "cannot connect to the VBoxVMI socket", no fallback)
VBOX_TEST_METHOD=vboxvmi / machinedebugger: same test ... ok
VBoxInternal/VMI/SocketPath=/tmp/lmv312/override.sock, default:
  INFO VirtualBox: VBoxVMI access method, socket "/tmp/lmv312/override.sock" ... ok

The full MICROVMI_TEST_FILTER=virtualbox_ suite passes under both default and default-fallback. Errors in the register-write test show which method served the request: VBoxVMI register write refused vs IMachineDebugger::SetRegisters failed. Read speed: 1350 MiB/s with VBoxVMI, 240 MiB/s with MachineDebugger.

Also run:

• cargo test --test virtualbox_errors with virtualbox-vmi and with virtualbox
• clippy -D warnings for virtualbox, virtualbox-api and virtualbox-vmi
• the Python unit tests (17 passed)

Merge Danger

Door: two-way

Blast Radius: VirtualBox callers

These changes break VirtualBox callers:

• Rust callers that build VBoxVMI { socket_path: String }
• matches on MicrovmiError::AccessMethodRequired

A caller that relied on "no access method is an error" now gets a VirtualBox driver. Autodetection (init(None, ..)) without VirtualBox params now also tries VirtualBox's default method.