Merge branch 'main' into main-live-migration-and-msync

.buildkite/pipeline_cross.py

@@ -38,7 +38,7 @@ def restore_step(label, src_instance, src_kv, dst_instance, dst_os, dst_kv):
 def cross_steps():
     """Generate group steps"""
     instances_x86_64 = ["c5n.metal", "m5n.metal", "m6i.metal", "m6a.metal"]
-    instances_aarch64 = ["m6g.metal", "m7g.metal"]
+    instances_aarch64 = ["m7g.metal"]
     groups = []
     commands = [
         "./tools/devtool -y build --release",
@@ -53,7 +53,7 @@ def cross_steps():
             commands,
             timeout=30,
             artifact_paths="snapshots/**/*",
-            instances=instances_x86_64 + instances_aarch64,
+            instances=instances_x86_64,
             platforms=DEFAULT_PLATFORMS,
         )
     )
@@ -65,15 +65,10 @@ def cross_steps():
         "c5n.metal": ["m5n.metal", "m6i.metal"],
         "m5n.metal": ["c5n.metal", "m6i.metal"],
         "m6i.metal": ["c5n.metal", "m5n.metal"],
-        "m6g.metal": ["m7g.metal"],
-        "m7g.metal": ["m6g.metal"],
     }
 
     # https://github.com/firecracker-microvm/firecracker/blob/main/docs/kernel-policy.md#experimental-snapshot-compatibility-across-kernel-versions
-    aarch64_platforms = [
-        ("al2", "linux_5.10"),
-        ("al2023", "linux_6.1"),
-    ]
+    aarch64_platforms = [("al2023", "linux_6.1")]
     perms_aarch64 = itertools.product(
         instances_aarch64, aarch64_platforms, instances_aarch64, aarch64_platforms
     )
@@ -91,8 +86,8 @@ def cross_steps():
         # the integration tests already test src == dst, so we skip it
         if src_instance == dst_instance and src_kv == dst_kv:
             continue
-        # 5.10 -> 4.14 is not supported
-        if dst_kv == "linux_4.14":
+        # newer -> older is not supported, and does not work
+        if src_kv > dst_kv:
             continue
         if src_instance != dst_instance and dst_instance not in supported.get(
             src_instance, []

.github/CODEOWNERS

@@ -1,19 +1,19 @@
 # All markdown files
-*.md @xmarcalx @kalyazin @pb8o @sudanl0
+*.md @xmarcalx @kalyazin @pb8o
 
 # But not the ones in docs/
 docs/*.md
 
 # Except these specific ones
-docs/getting-started.md @xmarcalx @kalyazin @pb8o @sudanl0
-docs/prod-host-setup.md @xmarcalx @kalyazin @pb8o @sudanl0
+docs/getting-started.md @xmarcalx @kalyazin @pb8o
+docs/prod-host-setup.md @xmarcalx @kalyazin @pb8o
 
 # Also cover all "*policy*.md" documents
-**/*policy*.md @xmarcalx @kalyazin @pb8o @sudanl0
-**/*POLICY*.md @xmarcalx @kalyazin @pb8o @sudanl0
+**/*policy*.md @xmarcalx @kalyazin @pb8o
+**/*POLICY*.md @xmarcalx @kalyazin @pb8o
 
 # Also these non-md files in the repository root
-THIRD_PARTY @xmarcalx @kalyazin @pb8o @sudanl0
-LICENSE @xmarcalx @kalyazin @pb8o @sudanl0
-NOTICE @xmarcalx @kalyazin @pb8o @sudanl0
-PGP-KEY.asc @xmarcalx @kalyazin @pb8o @sudanl0
+THIRD_PARTY @xmarcalx @kalyazin @pb8o
+LICENSE @xmarcalx @kalyazin @pb8o
+NOTICE @xmarcalx @kalyazin @pb8o
+PGP-KEY.asc @xmarcalx @kalyazin @pb8o

CHANGELOG.md

@@ -84,6 +84,12 @@ and this project adheres to
   UFFD support not being forward-compatible with new ioctl options introduced in
   Linux 6.6. See also
   https://github.com/bytecodealliance/userfaultfd-rs/issues/61.
+- [#4618](https://github.com/firecracker-microvm/firecracker/pull/4618): On
+  x86_64, when taking a snapshot, if a vCPU has MSR_IA32_TSC_DEADLINE set to 0,
+  Firecracker will replace it with the MSR_IA32_TSC value from the same vCPU.
+  This is to guarantee that the vCPU will continue receiving TSC interrupts
+  after restoring from the snapshot even if an interrupt is lost when taking a
+  snapshot.
 
 ## \[1.7.0\]
 

CONTRIBUTING.md

@@ -32,10 +32,10 @@ you want to merge your changes to Firecracker:
    against the main branch of the Firecracker repository.
 1. Add two reviewers to your pull request (a maintainer will do that for you if
    you're new). Work with your reviewers to address any comments and obtain a
-   minimum of 2 approvals, at least one of which must be provided by
-   [a maintainer](MAINTAINERS.md). To update your pull request amend existing
-   commits whenever applicable and then push the new changes to your pull
-   request branch.
+   minimum of 2 approvals from [maintainers](MAINTAINERS.md). To update your
+   pull request, amend existing commits whenever applicable. Then force-push the
+   new changes to your pull request branch. Address all review comments you
+   receive.
 1. Once the pull request is approved, one of the maintainers will merge it.
 
 ## Request for Comments
@@ -119,6 +119,33 @@ Your contribution needs to meet the following standards:
   }
   ```
 
+- Avoid using `Option::unwrap`/`Result::unwrap`. Prefer propagating errors
+  instead of aborting execution, or using `Option::expect`/`Result::except` if
+  no alternative exists. Leave a comment explaining why the code will not panic
+  in practice. Often, `unwrap`s are used because a previous check ensures they
+  are safe, e.g.
+
+  ```rs
+  let my_value: u32 = ...;
+  if my_value <= u16::MAX {
+      Ok(my_value.try_into::<u16>().unwrap())
+  } else {
+      Err(Error::Overflow)
+  }
+  ```
+
+  These can often be rewritten using `.map`/`.map_err` or `match`/`if let`
+  constructs such as
+
+  ```rs
+  my_value.try_into::<u16>()
+      .map_err(|_| Error::Overflow)
+  ```
+
+  See also
+  [this PR](https://github.com/firecracker-microvm/firecracker/pull/3557) for a
+  lot of examples.
+
 - Document your pull requests. Include the reasoning behind each change, and the
   testing done.