virtio: support dynamic device add

[Jaxtonmax]

virtio: support dynamic device add

Summary

Closes #57.

This PR adds a virtio add flow so new Virtio device configurations can be sent to an already running hvisor-tool Virtio backend daemon.

Main changes:

• Add hvisor virtio add <virtio.json> CLI support.
• Add a Unix domain socket control path at /run/hvisor-virtio.sock.
• Let virtio add act as a client while the running daemon performs the actual state mutation.
• Reuse the virtio start JSON parsing, memory mapping, validation, and device creation path for later add requests.
• Split device creation from publishing to vdevs[].
• Stage all enabled devices first, then publish them together only after all devices in the add request are created successfully.
• Clean up unpublished devices on failure, including blk, console, net, gpu, virtqueue, fd, event, worker thread, mutex, and cond resources where applicable.
• Document the new workflow in README.md and README-zh.md.

New Workflow

The existing one-shot startup flow is still supported:

nohup ./hvisor virtio start virtio_cfg.json &
./hvisor zone start zone1_linux.json

The new flow can add another Virtio configuration to the running daemon:

nohup ./hvisor virtio start virtio_start_empty.json &
./hvisor virtio add virtio_add_console_blk.json
./hvisor zone start zone1_linux.json

For MMIO Virtio devices, virtio add should be run before starting the zone that will use the newly added devices, unless full guest runtime hotplug is separately verified.

Implementation Notes

• virtio add connects to the daemon through /run/hvisor-virtio.sock.
• The daemon owns shared state such as vdevs[], zone_mem[], event monitor state, and device-specific resources.
• VDEV_MUTEX protects global device table publication and MMIO address publication.
• ZONE_MEM_MUTEX protects zone memory mapping records.
• Device creation is staged:
  • create unpublished devices into a local list
  • if any device fails, destroy staged devices and return failure
  • if all devices succeed, publish them into vdevs[] together
• Device cleanup paths now tolerate partially initialized state:
  • blk checks worker thread, image fd, mutex, and cond state
  • console removes epoll event and closes pty fds only when initialized
  • net removes epoll event and closes tap fd only when initialized
  • gpu records DRM/thread/synchronization state for safer cleanup

Validation

Runtime validation performed on QEMU AArch64 with QEMU 9.0.1:

• Started root Linux on QEMU AArch64.
• Started an empty Virtio daemon.
• Ran virtio add with console + wrong blk:
  • observed virtio add failed
  • confirmed no console pty residue was left in /dev/pts
• Ran virtio add with console + valid blk:
  • observed virtio add succeeded
  • started zone1 successfully
  • entered zone1 console
  • confirmed blk was accessible in the tested zone1 flow
• Also manually checked the old virtio start style flow after updating the hvisor side.

Static/local checks performed during the branch work:

git diff --check upstream/main...HEAD

Notes

• The runtime validation in this round focuses on blk + console.
• net and gpu normal runtime paths are not fully covered by this validation; their changes are mainly initialization-failure and cleanup-path hardening.

[Jaxtonmax]

@Inquisitor-201 @ForeverYolo Could you help review this PR when you have time? This PR mainly addresses #57 by adding dynamic Virtio device add support. Thanks!