Hugepages support for Firecracker

[roypat]

Changes

Adds initial support for backing guest memory with huge pages. They can be configured via the /machine-config API, with Firecracker supporting 2M hugetlbfs pages. Huge page configuration is stored in the snapshot state, and a snapshot will be restored into a VM whose huge pages configuration matches that of the VM from which the snapshot was taken (with the operation erroring out if this is not possible for some reason, e.g. if trying to restore a hugetlbfs backed snapshot by mmaping the memory file). For the initial devpreview release, features that would require explicit integration with huge pages (such as memory ballooning) are mutually exclusive with huge page support.

This is linked to the #2139.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following
Developer Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• If a specific issue led to this PR, this PR closes the issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• API changes follow the Runbook for Firecracker API changes.
• User-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.
• New TODOs link to an issue.
• Commits meet contribution quality standards.

---

• This functionality cannot be added in rust-vmm.

[codecov]

Codecov Report

Attention: 26 lines in your changes are missing coverage. Please review.

Comparison is base (1f3848f) 81.37% compared to head (e179b9f) 81.37%.

Files	Patch %	Lines
src/vmm/src/persist.rs	0.00%	15 Missing ⚠️
src/vmm/src/resources.rs	76.19%	5 Missing ⚠️
src/vmm/src/vmm_config/machine_config.rs	85.71%	5 Missing ⚠️
src/vmm/src/vstate/memory.rs	96.15%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4360   +/-   ##
=======================================
  Coverage   81.37%   81.37%           
=======================================
  Files         243      243           
  Lines       29431    29518   +87     
=======================================
+ Hits        23949    24021   +72     
- Misses       5482     5497   +15     

Flag	Coverage Δ
4.14-c5n.metal	78.66% <74.75%> (?)
4.14-c7g.metal	?
4.14-m5d.metal	?
4.14-m5n.metal	78.65% <74.75%> (?)
4.14-m6a.metal	77.77% <74.75%> (-0.01%)	⬇️
4.14-m6g.metal	76.73% <74.75%> (-0.01%)	⬇️
4.14-m6i.metal	78.64% <74.75%> (-0.01%)	⬇️
4.14-m7g.metal	76.73% <74.75%> (?)
5.10-c5n.metal	81.32% <73.78%> (?)
5.10-c7g.metal	?
5.10-m5d.metal	?
5.10-m5n.metal	81.31% <73.78%> (?)
5.10-m6a.metal	80.53% <73.78%> (-0.02%)	⬇️
5.10-m6g.metal	79.63% <73.78%> (-0.02%)	⬇️
5.10-m6i.metal	81.31% <73.78%> (-0.03%)	⬇️
5.10-m7g.metal	79.63% <73.78%> (?)
6.1-c5n.metal	81.32% <73.78%> (?)
6.1-m5n.metal	81.31% <73.78%> (?)
6.1-m6a.metal	80.53% <73.78%> (-0.02%)	⬇️
6.1-m6g.metal	79.63% <73.78%> (-0.02%)	⬇️
6.1-m6i.metal	81.31% <73.78%> (-0.03%)	⬇️
6.1-m7g.metal	79.63% <73.78%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[roypat]

@avirtuos tagging you in here for visibility. GitHub is not letting me explicitly add you as a review for some reason. This PR is where the initial huge pages work will take place :)

[ShadowCurse]

I don't really see an obvious way to label things that arent "fix", "doc" or "chore", and adding prefixes would force me to rewrite some commit titles due to the 70 char limit.

I would mark most of them as feat(huge-pages) or feat(uffd). Also most of commits have huge pages words in them, so replacing them with feat(huge-pages) will not be a huge change (even thought it is +6 chars)
Unfortunately we don't enforce conventional commit style, but we unofficially do it anyway and I think it is not extremely difficult to stick to it here.

[roypat]

Unfortunately we don't enforce conventional commit style, but we unofficially do it anyway and I think it is not extremely difficult to stick to it here.

Yes, as you mention, we do not enforce it, so we also should not insist on it on reviews, as its up to the author. I prefer to not put them outside of very unambiguous cases (e.g. doc commits).