[AprilNEA]

The HVC block device carried READ/WRITE/FLUSH only, so a Btrfs data disk on it advertised discard_max_bytes=0: discard=async did nothing, fstrim failed with "Not supported", and the host's sparse image never shrank after the guest freed space. Measured on the ArcBox System VM (HV backend): 5 GiB written and deleted left docker.img at 5.4 GiB indefinitely, while the same test on VZ (Apple virtio-blk) returned to 250 MiB within 3 minutes.

This adds ARCBOX_HVC_BLK_DISCARD (0xC2000005) and routes REQ_OP_DISCARD to it. A zero-length call at probe is the capability check: a host that implements the call answers 0, an older host answers the SMCCC "not supported" code through its PSCI fallback, and the device then stays exactly as before. Limits: 1 GiB per request (the host punches synchronously on the calling vCPU, ~20 ms per GiB of live data on APFS), 4 KiB granularity (what the host frees).

Host half: arcboxlabs/arcbox feat(vmm): punch DISCARDedranges on the HVC block fast path (virt/arcbox-vmm/src/vmm/darwin_hv/hvc_blk.rs). Either side alone is inert.

Verified with the CI-built kernel-arm64 from this branch booted under an arcbox HV dev daemon: arcbox_hvc_blk: /dev/arcboxhvc1 (device 1, rw, discard), discard_max_bytes=1073741824, and the 5 GiB write/delete matrix now reclaims on HV (numbers in the arcbox change's docs/disk-reclaim.md).

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-27T11:19:58.372865Z	5bf089c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[greptile-apps]

Confidence Score: 4/5

[High risk] Adds block device discard support to hypervisor driver.

The PR appears safe to merge, with non-blocking regression coverage recommended for discard compatibility and boundary cases.

Findings

1.  Discard boundary coverage is missing ▶

Summary

The PR adds a discard hypercall to the HVC block driver, enables discard limits when a zero-length capability probe succeeds, and forwards discard requests to the host.

• The remaining review concern is regression coverage for host compatibility and small discard ranges.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Probe block device] --> B[Zero-length DISCARD hypercall]
  B -->|Supported| C[Advertise discard limits]
  B -->|Unsupported| D[Keep discard disabled]
  C --> E[Block-layer DISCARD request]
  E --> F[Forward sector range to host]

Loading

_{Reviews (1) · Last reviewed commit: "feat(hvc_blk): issue DISCARD to the host..."}