Goal
Prove the DAX fast path (guest mmap → FUSE_SETUPMAPPING → hv_vm_map → guest page fault serviced from host mapping) actually triggers, and that HvDaxMapper::stats() reports the expected counter increments.
Why this is separate from ABX-362
ABX-362's bytes-match assertion passed at 4 KiB, but with that size the guest kernel chose FUSE_READ (copy-through) instead of DAX — DaxStats::setup_mappings_count stayed at 0. The host-side DAX path is wired and covered by unit tests; what we still need is a guest-side trigger large enough that the FUSE client prefers DAX.
Blocker
Requires the companion fix for the vsock truncation bug (see sibling issue on partial-write handling). Without it, any response larger than ~8 KiB is truncated and the test can't complete.
Scope
Once the vsock fix lands:
- Bump the
hv_e2e.rs DAX fixture size from 4 KiB to ≥ 128 KiB (or whatever the FUSE kernel's DAX threshold is — the arcbox kernel config has CONFIG_FUSE_DAX=y; check the threshold at runtime).
- Restore the gating assertions:
after.setup_mappings_count > before.setup_mappings_count — SETUPMAPPING fired.after.setup_mappings_bytes >= fixture_length — bytes advised match.
- Optionally: unmap test — issue a
MunmapFile RPC (to be added) and assert remove_mappings_count increased.
Informational measurement
While we're here, capture and log:
- Wall time for DAX read vs. re-run with
MADV_DONTNEED forcing re-fault.
- FUSE_READ request count before/after (needs new counter in
FuseDispatcher).
These are not gating but useful for future regressions.
Files
app/arcbox-core/examples/hv_e2e.rs — size + assertion tweaks.virt/arcbox-virtio-fs/src/device.rs — optional FUSE_READ counter.
Acceptance
- With the vsock fix in place, the E2E harness passes with a DAX fixture ≥ 128 KiB.
DaxStats shows setup_mappings_count >= 1 and setup_mappings_bytes >= 128 KiB.
Goal
Prove the DAX fast path (guest
mmap→FUSE_SETUPMAPPING→hv_vm_map→ guest page fault serviced from host mapping) actually triggers, and thatHvDaxMapper::stats()reports the expected counter increments.Why this is separate from ABX-362
ABX-362's bytes-match assertion passed at 4 KiB, but with that size the guest kernel chose
FUSE_READ(copy-through) instead of DAX —DaxStats::setup_mappings_countstayed at 0. The host-side DAX path is wired and covered by unit tests; what we still need is a guest-side trigger large enough that the FUSE client prefers DAX.Blocker
Requires the companion fix for the vsock truncation bug (see sibling issue on partial-write handling). Without it, any response larger than ~8 KiB is truncated and the test can't complete.
Scope
Once the vsock fix lands:
hv_e2e.rsDAX fixture size from 4 KiB to ≥ 128 KiB (or whatever the FUSE kernel's DAX threshold is — the arcbox kernel config hasCONFIG_FUSE_DAX=y; check the threshold at runtime).after.setup_mappings_count > before.setup_mappings_count— SETUPMAPPING fired.after.setup_mappings_bytes >= fixture_length— bytes advised match.MunmapFileRPC (to be added) and assertremove_mappings_countincreased.Informational measurement
While we're here, capture and log:
MADV_DONTNEEDforcing re-fault.FuseDispatcher).These are not gating but useful for future regressions.
Files
app/arcbox-core/examples/hv_e2e.rs— size + assertion tweaks.virt/arcbox-virtio-fs/src/device.rs— optional FUSE_READ counter.Acceptance
DaxStatsshowssetup_mappings_count >= 1andsetup_mappings_bytes >= 128 KiB.