feat: add virtiofs support for Linux guests

[codemedic]

Description

Adds automatic virtiofs support for Linux guests. When the standalone virtiofsd is installed on the host and public_dir is set, quickemu will use vhost-user-fs-pci (virtiofs) instead of virtio-9p-pci. Falls back silently to 9p if virtiofsd is not found or fails to start.

Related: #1892

Why

9p performance is poor for metadata-heavy workloads (git, builds, package managers) due to per-syscall round-trip overhead. virtiofs uses a shared memory region (/dev/shm) instead, giving much lower latency and near-native throughput. No guest changes are needed — virtiofs has been built into the Linux kernel since 5.4.

Type of change

• New feature (non-breaking change which adds functionality)

Behaviour

No configuration changes needed — fully automatic. When virtiofsd is active, the VM output shows:

 - virtiofsd: /home/user/.quickemu/myvm/myvm.virtiofsd-sock (12345)
 - virtiofs: On guest: sudo mount -t virtiofs Public-user ~/Public

If virtiofsd is absent or fails to start, quickemu falls back to 9p with no user action required.

Installing virtiofsd

The standalone Rust virtiofsd is required — the legacy QEMU-bundled C daemon (/usr/lib/qemu/virtiofsd) uses incompatible CLI syntax and is not supported.

Fedora / recent distros: available as a package:

sudo dnf install virtiofsd        # Fedora
sudo apt install virtiofsd        # Ubuntu 24.04+

Ubuntu 22.04 (build from source):

sudo apt install libcap-ng-dev libseccomp-dev
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.cargo/env
git clone https://gitlab.com/virtio-fs/virtiofsd.git
cd virtiofsd && cargo build --release
sudo cp target/release/virtiofsd /usr/local/bin/

Checklist:

• I have performed a self-review of my code
• I have tested my code in common scenarios and confirmed there are no regressions
• I have added comments to my code, particularly in hard-to-understand sections
• I have made corresponding changes to the documentation

[cubic-dev-ai]

3 issues found across 2 files

Confidence score: 3/5

• There is concrete user-impact risk in quickemu: stop_virtiofsd may act on stale PID-file data and signal an unrelated process after PID reuse, which raises operational safety concerns.
• quickemu also appears to force the virtiofs path once virtiofsd starts without checking QEMU support, so unsupported environments can fail VM startup instead of falling back to 9p.
• Given the medium-to-high severities (6–7/10) and strong confidence, this is not merge-blocking by default but carries meaningful regression risk that should be addressed soon.
• Pay close attention to quickemu and README.md - process handling/fallback behavior in quickemu, and documentation accuracy around virtiofs prerequisites in README.md.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="README.md">

<violation number="1" location="README.md:50">
P2: README overstates virtiofs auto-preference by omitting that a valid public share directory (`public_dir`/`PUBLIC`) is also required.</violation>
</file>

<file name="quickemu">

<violation number="1" location="quickemu:1688">
P1: `stop_virtiofsd` trusts stale PID-file values and may signal unrelated processes after PID reuse.</violation>

<violation number="2" location="quickemu:2148">
P2: Virtiofs path is selected unconditionally once `virtiofsd` starts, with no QEMU capability check; unsupported setups fail VM startup instead of falling back to 9p.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="quickemu">

<violation number="1" location="quickemu:2580">
P2: Virtiofs enablement is gated on `iso` before storage boot mode is resolved, so VMs with persistent `iso` config can incorrectly lose virtiofs on normal disk boots.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

2 issues found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="quickemu">

<violation number="1" location="quickemu:1660">
P2: virtiofsd readiness check is racy (fixed sleep + socket-only probe), which can mis-detect startup and leak/orphan daemon processes.</violation>

<violation number="2" location="quickemu:1678">
P1: PID capture via `pgrep -f ... | head -1` is unsafe and can persist/kill the wrong process.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

3 issues found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="quickemu">

<violation number="1" location="quickemu:1689">
P1: Fallback PID lookup can select an unrelated `virtiofsd` process because it uses a global `pgrep -f "virtiofsd"` instead of matching the VM socket.</violation>

<violation number="2" location="quickemu:1712">
P2: Linux-specific `/proc/<pid>/comm` PID validation is used without host-OS guarding, which can break virtiofsd PID tracking and shutdown on non-Linux hosts.</violation>

<violation number="3" location="quickemu:2179">
P2: QEMU virtiofs capability check can false-positive by matching error text, preventing intended fallback to 9p on unsupported builds.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="quickemu">

<violation number="1" location="quickemu:1689">
P2: Unescaped socket path is used as a `pgrep -f` regex pattern, so fallback PID detection can fail/mis-match and break virtiofsd cleanup.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

_{Requires human review: Significant feature addition involving process management and QEMU configuration logic; requires human review for potential impact on VM lifecycle and guest compatibility.}