pass vm_config to eliminate two extra arguments derived from it

Signed-off-by: tommady <tommady@users.noreply.github.com>

remove cfg_attr and extract create_vcpus from create_vmm_and_vcpus

Signed-off-by: tommady <tommady@users.noreply.github.com>

extract codes into two architecture specific modes

Signed-off-by: tommady <tommady@users.noreply.github.com>

eliminate the unnecessary usage of the event_manager argument

Signed-off-by: tommady <tommady@users.noreply.github.com>

Add the SVE CPU template as a valid template in 5.10 since it works.

Signed-off-by: Pablo Barbáchano <pablob@amazon.com>

Update release policy to v1.10.1 patch

Signed-off-by: Jack Thomson <jackabt@amazon.com>

`TcpIPv4Handler` for MMDS network stack preallocates several buffers
whose sizes are saved into a snapshot as `max_connections` and
`max_pending_resets` in `MmdsNetworkStackState`. But they are always the
same constant hardcoded values (`DEFAULT_MAX_CONNECTIONS` and
`DEFAULT_MAX_PENDING_RESETS`) as of today, which means there is no need
to save them into a snapshot. Even if we change the hardcoded sizes
across Firecracker versions, that should not be a problem. This is
because the snapshot feature does not support migration of network
connections and those buffers are initialized with empty on snapshot
restoration. When migrating from a Firecracker version with larger
buffers to another version with smaller ones, guest workloads that
worked previously might start to fail due to the less buffer spaces.
However, the issue is not a problem of the snapshot feature and it
should also occur even on a purely booted microVM (not restored from a
snapshot). Thus, it is fine to remove those fields from a snapshot.

Since this is a breaking change of the snapshot format, bumps the major
version.

Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

There is no need to use MmdsNetworkStack::new() instead of
MmdsNetworkStack::new_with_defaults() in tests that pass the same
default values.

Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We bumped the snapshot version up twice recently, requiring users to
regenerate their snapshot, but the user action isn't clearly stated.

Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

eliminate the unnecessary usage of the event_manager argument and
fix up aarch64 attach_legacy_devices_aarch64 fn

Signed-off-by: tommady <tommady@users.noreply.github.com>

remove the aarch64 suffix from the attach_legacy_devices_aarch64
function and ensure that aarch64 smt is always set to false int the
configure_system_for_boot function

Signed-off-by: tommady <tommady@users.noreply.github.com>

`TcpIPv4Handler` for MMDS network stack preallocates several buffers
whose sizes are saved into a snapshot as `max_connections` and
`max_pending_resets` in `MmdsNetworkStackState`. But they are always the
same constant hardcoded values (`DEFAULT_MAX_CONNECTIONS` and
`DEFAULT_MAX_PENDING_RESETS`) as of today, which means there is no need
to save them into a snapshot. Even if we change the hardcoded sizes
across Firecracker versions, that should not be a problem. This is
because the snapshot feature does not support migration of network
connections and those buffers are initialized with empty on snapshot
restoration. When migrating from a Firecracker version with larger
buffers to another version with smaller ones, guest workloads that
worked previously might start to fail due to the less buffer spaces.
However, the issue is not a problem of the snapshot feature and it
should also occur even on a purely booted microVM (not restored from a
snapshot). Thus, it is fine to remove those fields from a snapshot.

Since this is a breaking change of the snapshot format, bumps the major
version.

Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We bumped the snapshot version up twice recently, requiring users to
regenerate their snapshot, but the user action isn't clearly stated.

Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

let the x86_64 and aarch64 architectures code can compile and without
warnning

Signed-off-by: tommady <tommady@users.noreply.github.com>