fix: Retry KVM_CREATE_VM on EINTR

[zulinx86]

Reason & Changes

It is known that KVM_CREATE_VM occasionally fails with EINTR on heavily loaded machines
with many VMs.

The behavior itself that KVM_CREATE_VM can return EINTR is intentional. This is because
the KVM_CREATE_VM path includes mm_take_all_locks() that is CPU intensive and all CPU
intensive syscalls should check for pending signals and return EINTR immediately to allow
userland to remain interactive.
https://lists.nongnu.org/archive/html/qemu-devel/2014-01/msg01740.html

However, it is empirically confirmed that, even though there is no pending signal,
KVM_CREATE_VM returns EINTR.
https://lore.kernel.org/qemu-devel/[email protected]/

To mitigate it, QEMU does an inifinite retry on EINTR that greatly improves reliabiliy:

• qemu/qemu@94ccff1
• qemu/qemu@bbde13c

Similarly, we do retries up to 5 times. Although Firecracker clients are also able to
retry, they have to start Firecracker from scratch. Doing retries in Firecracker makes
recovery faster and improves reliability.

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

• I have read and understand CONTRIBUTING.md.
• I have run tools/devtool checkstyle to verify that the PR passes the
  automated style checks.
• I have described what is done in these changes, why they are needed, and
  how they are solving the problem in a clear and encompassing way.
• [ ] I have updated any relevant documentation (both in code and in the docs)
  in the PR.
• [ ] I have mentioned all user-facing changes in CHANGELOG.md.
• [ ] If a specific issue led to this PR, this PR closes the issue.
• [ ] When making API changes, I have followed the
  Runbook for Firecracker API changes.
• I have tested all new and changed functionalities in unit tests and/or
  integration tests.
• I have linked an issue to every new TODO.

---

• This functionality cannot be added in rust-vmm.

[zulinx86]

Question:

• Do we want to add TODO comment and track it as an issue?
• Should the log level be "warn"?
• Do we want to have a metric to gather data of how often it fails with EINTR? (maybe no, because its removal is going to be a breaking change).

[codecov]

Codecov Report

Attention: Patch coverage is 58.33333% with 5 lines in your changes missing coverage. Please review.

Project coverage is 83.19%. Comparing base (26a3a1e) to head (5e0efad).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/vmm/src/vstate/vm/mod.rs	50.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5046      +/-   ##
==========================================
- Coverage   83.20%   83.19%   -0.02%     
==========================================
  Files         247      247              
  Lines       26631    26641      +10     
==========================================
+ Hits        22158    22163       +5     
- Misses       4473     4478       +5     

Flag	Coverage Δ
5.10-c5n.metal	83.67% <54.54%> (-0.02%)	⬇️
5.10-m5n.metal	83.66% <54.54%> (-0.02%)	⬇️
5.10-m6a.metal	82.86% <54.54%> (-0.02%)	⬇️
5.10-m6g.metal	79.66% <54.54%> (-0.02%)	⬇️
5.10-m6i.metal	83.65% <54.54%> (-0.02%)	⬇️
5.10-m7g.metal	79.66% <54.54%> (-0.02%)	⬇️
6.1-c5n.metal	83.67% <54.54%> (-0.01%)	⬇️
6.1-m5n.metal	83.66% <54.54%> (-0.02%)	⬇️
6.1-m6a.metal	82.86% <54.54%> (-0.02%)	⬇️
6.1-m6g.metal	79.65% <54.54%> (-0.02%)	⬇️
6.1-m6i.metal	83.65% <54.54%> (-0.02%)	⬇️
6.1-m7g.metal	79.66% <54.54%> (-0.02%)	⬇️

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.