{"owner":"hyperlight-dev","repo":"hyperlight","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md"],"skills":{".github/copilot-instructions.md":"# Hyperlight: Copilot instructions\n\nHyperlight is a lightweight Virtual Machine Manager (VMM) embedded within\napplications to run untrusted code inside micro virtual machines with very low\nlatency and minimal overhead. Mostly Rust, with a few C files. `just` is the\ntask runner and is already installed.\n\n## Build & test commands\n\nMost recipes take an optional profile argument that defaults to debug. Append\n`release` for a release build (e.g. `just build release`). You rarely need to\nrun both profiles for one change.\n\n* `just build`: build the host and libraries.\n* `just guests`: build the guest library and test guests (both profiles).\n* `just test`: run all tests.\n* `just fmt-apply`: format and apply fixes.\n* `just clippy`: lint.\n* `just clippyw`: cross-compile clippy for Windows. Run it on Linux when you\n  edit Windows-specific code.\n* `just test-like-ci`: full CI-equivalent run. Slow.\n\n**Run `just guests` before `just test` when you've changed guest code.**\nTests use the prebuilt guest binaries, so rebuild them to pick up guest\nchanges. Not needed if you only touched host code.\n\n## Definition of done\n\nBefore considering a change complete:\n1. `just fmt-apply`.\n2. `just clippy` passes.\n3. `just test` passes. Run `just guests` first if you changed guest code.\n   Tests are slow. Run the release profile too only when the change\n   specifically warrants it.\n4. New code has tests and rustdoc following existing patterns.\n5. Docs updated if behavior documented in `README.md` or `docs/` changed.\n\n## Code conventions\n\n* Follow idiomatic Rust and match the surrounding code style.\n* Do not add new crates or dependencies without discussing first.\n* Maintain the existing structure and organization. Do not refactor beyond\n  what the task requires.\n* Do not commit large binary files.\n\n## Writing\n\nApplies to all writing: code comments, docstrings, docs, commit messages, PR\ndescriptions. Conciseness is the top rule. The rest serves it.\n\nBe concise.\n* Use the fewest words that make the point. No filler.\n* Say each point once. Never restate the same idea in other words.\n* Cut anything the reader can see in the code or context.\n* Short plain sentences, one clause each. Common everyday words.\n\nMechanics.\n* No em dashes or hyphens as prose connectors. Use periods or commas.\n* No semicolons. Use periods.\n* Prefer `*` over `-` for bullets.\n\nSay what IS, not what changed or what it isn't.\n* Write what the thing IS and WHY. The reader has no knowledge of the diff\n  that introduced it. Git history is where to learn what changed.\n* Avoid contrastive language (\"no longer\", \"previously\", \"instead of\",\n  \"used to\", \"now\", \"just\").\n* Avoid diff narration (\"moved from\", \"extracted from\", \"X drops here\").\n* No PR or review references unless permanently relevant.\n\nComment only when needed.\n* Skip comments the code or a descriptive name already makes clear.\n* A docstring that restates the function or test name is noise. Drop it.\n* Keep comments that explain a non-obvious mechanism or a real WHY.\n* Default 1-2 sentences for a docstring, 1 short line for an inline comment.\n  If it does not fit, the code probably needs to be simpler.\n\n## Git & commits\n\n* Sign commits (`commit.gpgsign=true`) and add `--signoff` for DCO.\n* Keep commits small, focused, and in logical order.\n* Rebase your branch on `main`. No merge commits.\n* Label PRs per `docs/github-labels.md`.\n\n## Reviewing code\n\nWhen reviewing a diff (your own or a PR), weight these for Hyperlight:\n* Correctness: edge cases, error paths, broken invariants.\n* Security boundary: the VMM/guest split, paging, and syscall surface. Treat\n  all guest input as untrusted and watch for sandbox-escape risk.\n* Unsafe: every `unsafe` block needs an accurate `// SAFETY:` comment and\n  every `unsafe fn` a `# Safety` rustdoc precondition. Check soundness: the\n  block must uphold the invariants it claims. A fn is `unsafe fn` only when a\n  caller must uphold a precondition for memory safety. Flag both missing and\n  gratuitous `unsafe`.\n* Necessity: challenge each added abstraction, field, variant, parameter, branch.\n  If nothing exercises it, say so, and prefer the simpler form.\n* Design: judge the seams and boundaries the change draws (module/crate\n  splits, what gets serialized, public vs private, where state lives). Prefer\n  fitting an existing pattern over a parallel second way.\n* Performance: review every change for cost. Look for work that can be\n  dropped or made cheaper, including hot-path allocations, unnecessary copies,\n  lock contention, syscalls, hypercalls.\n* Idioms: do not reinvent what std or an existing dependency already provides.\n* Changelog: user-facing changes need a `CHANGELOG.md` entry. Internal-only\n  changes do not.\n* External APIs (Win32, POSIX, KVM/mshv/WHP): verify calls against the\n  authoritative docs rather than from memory.\n\n## Agent behavior\n\n* When the user asks a question, analyze and answer only. Do not edit code\n  until explicitly asked.\n\n## Repository structure\n\n* `src/hyperlight_common/`: code shared between host and guest.\n* `src/hyperlight_guest/`: hyperlight-guest library.\n* `src/hyperlight_guest_bin/`: hyperlight-guest-bin library.\n* `src/hyperlight_guest_capi/`: guest C library.\n* `src/hyperlight_host/`: hyperlight-host library.\n* `src/hyperlight_testing/`: shared test code.\n* `schema/`: flatbuffer schemas.\n* `tests/`: test guest code in C and Rust.\n* `dev/`: development scripts and tools.\n* `fuzz/`: fuzzing tests.\n* `Justfile`: build/test/run tasks.\n\n## Troubleshooting\n\n* **\"No Hypervisor was found for Sandbox\"** on Linux: check for a `kvm` or\n  `mshv` device in `/dev`, and that you have rw access to it. Output the\n  results of both checks for diagnostics.\n"},"files":{".github/copilot-instructions.md":"# Hyperlight: Copilot instructions\n\nHyperlight is a lightweight Virtual Machine Manager (VMM) embedded within\napplications to run untrusted code inside micro virtual machines with very low\nlatency and minimal overhead. Mostly Rust, with a few C files. `just` is the\ntask runner and is already installed.\n\n## Build & test commands\n\nMost recipes take an optional profile argument that defaults to debug. Append\n`release` for a release build (e.g. `just build release`). You rarely need to\nrun both profiles for one change.\n\n* `just build`: build the host and libraries.\n* `just guests`: build the guest library and test guests (both profiles).\n* `just test`: run all tests.\n* `just fmt-apply`: format and apply fixes.\n* `just clippy`: lint.\n* `just clippyw`: cross-compile clippy for Windows. Run it on Linux when you\n  edit Windows-specific code.\n* `just test-like-ci`: full CI-equivalent run. Slow.\n\n**Run `just guests` before `just test` when you've changed guest code.**\nTests use the prebuilt guest binaries, so rebuild them to pick up guest\nchanges. Not needed if you only touched host code.\n\n## Definition of done\n\nBefore considering a change complete:\n1. `just fmt-apply`.\n2. `just clippy` passes.\n3. `just test` passes. Run `just guests` first if you changed guest code.\n   Tests are slow. Run the release profile too only when the change\n   specifically warrants it.\n4. New code has tests and rustdoc following existing patterns.\n5. Docs updated if behavior documented in `README.md` or `docs/` changed.\n\n## Code conventions\n\n* Follow idiomatic Rust and match the surrounding code style.\n* Do not add new crates or dependencies without discussing first.\n* Maintain the existing structure and organization. Do not refactor beyond\n  what the task requires.\n* Do not commit large binary files.\n\n## Writing\n\nApplies to all writing: code comments, docstrings, docs, commit messages, PR\ndescriptions. Conciseness is the top rule. The rest serves it.\n\nBe concise.\n* Use the fewest words that make the point. No filler.\n* Say each point once. Never restate the same idea in other words.\n* Cut anything the reader can see in the code or context.\n* Short plain sentences, one clause each. Common everyday words.\n\nMechanics.\n* No em dashes or hyphens as prose connectors. Use periods or commas.\n* No semicolons. Use periods.\n* Prefer `*` over `-` for bullets.\n\nSay what IS, not what changed or what it isn't.\n* Write what the thing IS and WHY. The reader has no knowledge of the diff\n  that introduced it. Git history is where to learn what changed.\n* Avoid contrastive language (\"no longer\", \"previously\", \"instead of\",\n  \"used to\", \"now\", \"just\").\n* Avoid diff narration (\"moved from\", \"extracted from\", \"X drops here\").\n* No PR or review references unless permanently relevant.\n\nComment only when needed.\n* Skip comments the code or a descriptive name already makes clear.\n* A docstring that restates the function or test name is noise. Drop it.\n* Keep comments that explain a non-obvious mechanism or a real WHY.\n* Default 1-2 sentences for a docstring, 1 short line for an inline comment.\n  If it does not fit, the code probably needs to be simpler.\n\n## Git & commits\n\n* Sign commits (`commit.gpgsign=true`) and add `--signoff` for DCO.\n* Keep commits small, focused, and in logical order.\n* Rebase your branch on `main`. No merge commits.\n* Label PRs per `docs/github-labels.md`.\n\n## Reviewing code\n\nWhen reviewing a diff (your own or a PR), weight these for Hyperlight:\n* Correctness: edge cases, error paths, broken invariants.\n* Security boundary: the VMM/guest split, paging, and syscall surface. Treat\n  all guest input as untrusted and watch for sandbox-escape risk.\n* Unsafe: every `unsafe` block needs an accurate `// SAFETY:` comment and\n  every `unsafe fn` a `# Safety` rustdoc precondition. Check soundness: the\n  block must uphold the invariants it claims. A fn is `unsafe fn` only when a\n  caller must uphold a precondition for memory safety. Flag both missing and\n  gratuitous `unsafe`.\n* Necessity: challenge each added abstraction, field, variant, parameter, branch.\n  If nothing exercises it, say so, and prefer the simpler form.\n* Design: judge the seams and boundaries the change draws (module/crate\n  splits, what gets serialized, public vs private, where state lives). Prefer\n  fitting an existing pattern over a parallel second way.\n* Performance: review every change for cost. Look for work that can be\n  dropped or made cheaper, including hot-path allocations, unnecessary copies,\n  lock contention, syscalls, hypercalls.\n* Idioms: do not reinvent what std or an existing dependency already provides.\n* Changelog: user-facing changes need a `CHANGELOG.md` entry. Internal-only\n  changes do not.\n* External APIs (Win32, POSIX, KVM/mshv/WHP): verify calls against the\n  authoritative docs rather than from memory.\n\n## Agent behavior\n\n* When the user asks a question, analyze and answer only. Do not edit code\n  until explicitly asked.\n\n## Repository structure\n\n* `src/hyperlight_common/`: code shared between host and guest.\n* `src/hyperlight_guest/`: hyperlight-guest library.\n* `src/hyperlight_guest_bin/`: hyperlight-guest-bin library.\n* `src/hyperlight_guest_capi/`: guest C library.\n* `src/hyperlight_host/`: hyperlight-host library.\n* `src/hyperlight_testing/`: shared test code.\n* `schema/`: flatbuffer schemas.\n* `tests/`: test guest code in C and Rust.\n* `dev/`: development scripts and tools.\n* `fuzz/`: fuzzing tests.\n* `Justfile`: build/test/run tasks.\n\n## Troubleshooting\n\n* **\"No Hypervisor was found for Sandbox\"** on Linux: check for a `kvm` or\n  `mshv` device in `/dev`, and that you have rw access to it. Output the\n  results of both checks for diagnostics.\n"},"items":[{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# Hyperlight: Copilot instructions\n\nHyperlight is a lightweight Virtual Machine Manager (VMM) embedded within\napplications to run untrusted code inside micro virtual machines with very low\nlatency and minimal overhead. Mostly Rust, with a few C files. `just` is the\ntask runner and is already installed.\n\n## Build & test commands\n\nMost recipes take an optional profile argument that defaults to debug. Append\n`release` for a release build (e.g. `just build release`). You rarely need to\nrun both profiles for one change.\n\n* `just build`: build the host and libraries.\n* `just guests`: build the guest library and test guests (both profiles).\n* `just test`: run all tests.\n* `just fmt-apply`: format and apply fixes.\n* `just clippy`: lint.\n* `just clippyw`: cross-compile clippy for Windows. Run it on Linux when you\n  edit Windows-specific code.\n* `just test-like-ci`: full CI-equivalent run. Slow.\n\n**Run `just guests` before `just test` when you've changed guest code.**\nTests use the prebuilt guest binaries, so rebuild them to pick up guest\nchanges. Not needed if you only touched host code.\n\n## Definition of done\n\nBefore considering a change complete:\n1. `just fmt-apply`.\n2. `just clippy` passes.\n3. `just test` passes. Run `just guests` first if you changed guest code.\n   Tests are slow. Run the release profile too only when the change\n   specifically warrants it.\n4. New code has tests and rustdoc following existing patterns.\n5. Docs updated if behavior documented in `README.md` or `docs/` changed.\n\n## Code conventions\n\n* Follow idiomatic Rust and match the surrounding code style.\n* Do not add new crates or dependencies without discussing first.\n* Maintain the existing structure and organization. Do not refactor beyond\n  what the task requires.\n* Do not commit large binary files.\n\n## Writing\n\nApplies to all writing: code comments, docstrings, docs, commit messages, PR\ndescriptions. Conciseness is the top rule. The rest serves it.\n\nBe concise.\n* Use the fewest words that make the point. No filler.\n* Say each point once. Never restate the same idea in other words.\n* Cut anything the reader can see in the code or context.\n* Short plain sentences, one clause each. Common everyday words.\n\nMechanics.\n* No em dashes or hyphens as prose connectors. Use periods or commas.\n* No semicolons. Use periods.\n* Prefer `*` over `-` for bullets.\n\nSay what IS, not what changed or what it isn't.\n* Write what the thing IS and WHY. The reader has no knowledge of the diff\n  that introduced it. Git history is where to learn what changed.\n* Avoid contrastive language (\"no longer\", \"previously\", \"instead of\",\n  \"used to\", \"now\", \"just\").\n* Avoid diff narration (\"moved from\", \"extracted from\", \"X drops here\").\n* No PR or review references unless permanently relevant.\n\nComment only when needed.\n* Skip comments the code or a descriptive name already makes clear.\n* A docstring that restates the function or test name is noise. Drop it.\n* Keep comments that explain a non-obvious mechanism or a real WHY.\n* Default 1-2 sentences for a docstring, 1 short line for an inline comment.\n  If it does not fit, the code probably needs to be simpler.\n\n## Git & commits\n\n* Sign commits (`commit.gpgsign=true`) and add `--signoff` for DCO.\n* Keep commits small, focused, and in logical order.\n* Rebase your branch on `main`. No merge commits.\n* Label PRs per `docs/github-labels.md`.\n\n## Reviewing code\n\nWhen reviewing a diff (your own or a PR), weight these for Hyperlight:\n* Correctness: edge cases, error paths, broken invariants.\n* Security boundary: the VMM/guest split, paging, and syscall surface. Treat\n  all guest input as untrusted and watch for sandbox-escape risk.\n* Unsafe: every `unsafe` block needs an accurate `// SAFETY:` comment and\n  every `unsafe fn` a `# Safety` rustdoc precondition. Check soundness: the\n  block must uphold the invariants it claims. A fn is `unsafe fn` only when a\n  caller must uphold a precondition for memory safety. Flag both missing and\n  gratuitous `unsafe`.\n* Necessity: challenge each added abstraction, field, variant, parameter, branch.\n  If nothing exercises it, say so, and prefer the simpler form.\n* Design: judge the seams and boundaries the change draws (module/crate\n  splits, what gets serialized, public vs private, where state lives). Prefer\n  fitting an existing pattern over a parallel second way.\n* Performance: review every change for cost. Look for work that can be\n  dropped or made cheaper, including hot-path allocations, unnecessary copies,\n  lock contention, syscalls, hypercalls.\n* Idioms: do not reinvent what std or an existing dependency already provides.\n* Changelog: user-facing changes need a `CHANGELOG.md` entry. Internal-only\n  changes do not.\n* External APIs (Win32, POSIX, KVM/mshv/WHP): verify calls against the\n  authoritative docs rather than from memory.\n\n## Agent behavior\n\n* When the user asks a question, analyze and answer only. Do not edit code\n  until explicitly asked.\n\n## Repository structure\n\n* `src/hyperlight_common/`: code shared between host and guest.\n* `src/hyperlight_guest/`: hyperlight-guest library.\n* `src/hyperlight_guest_bin/`: hyperlight-guest-bin library.\n* `src/hyperlight_guest_capi/`: guest C library.\n* `src/hyperlight_host/`: hyperlight-host library.\n* `src/hyperlight_testing/`: shared test code.\n* `schema/`: flatbuffer schemas.\n* `tests/`: test guest code in C and Rust.\n* `dev/`: development scripts and tools.\n* `fuzz/`: fuzzing tests.\n* `Justfile`: build/test/run tasks.\n\n## Troubleshooting\n\n* **\"No Hypervisor was found for Sandbox\"** on Linux: check for a `kvm` or\n  `mshv` device in `/dev`, and that you have rw access to it. Output the\n  results of both checks for diagnostics.\n","category":".github","tokens":1426}]}