[Pedro Henrique Penna (ppenna)]

Lets a platform restore hand its clone an activation record in the restore packet, for microsoft/nvx#544. A platform clone takes the settings of its own launch, its activation record, from its host after the restore: NVX's guest waits, once it has acknowledged the restore, for the record in an Activate on its control session, which the host sends only once it has connected. The record is small, bounded, and carries no secret, so the restore packet, which the guest reads before it acknowledges the restore, can carry it, sealed before the first restored vCPU runs.

One commit on 6cb6ba87c, the head of feature/microvm/dev. microsoft/nvx#1419, part of microsoft/nvx#544, pins this head.

Carry a clone's activation record in the restore packet (d501e5066)

• Change. Bit 5 of the packet's flags, FLAG_ACTIVATION, which was reserved, says that the packet ends, after the DNS server record, with the record's length, a little-endian u32 from 1 to 1024 (MAX_RESTORE_ACTIVATION_LEN), then the record's bytes, which OpenVMM passes to the guest without interpreting them. RestorePacketBase::activation carries them; encode and decode lay them out and bound them, with RestorePacketError::Activation for an empty or oversized record.
• Options. --restore-activation-record PATH, and the management RPC's MicrovmSnapshotConfig.restore_activation_record_path (15), which the server converts to it as it converts the other restore fields, read the record in prepare_restore, before any vCPU runs, reading at most one byte past the bound. Only a platform snapshot admits it: a snapshot of a later tier continues a tenant's workload with the settings that it was captured with, and one without a tier has no activation. Such a restore gates host input until the guest acknowledges it, so the guest reads the record before host input reaches it.
• Layout. The u32 length keeps the record on a four-byte boundary of the packet (24-byte header, 16-byte ranges, 64 bytes of entropy, 16-byte DNS server, 4-byte length), since the guest reads the packet four bytes per port access, and a read split across the length and the record would drop bytes.
• Alternatives. A new packet version would refuse every snapshot whose guest decodes only version 1, even at restores that carry no record. The packet stays version 1 instead: every guest that decodes version 1 refuses a packet that sets a reserved flag bit, so a guest that predates the flag fails a restore that hands it a record rather than ignore the record, and a packet without the flag keeps its layout and meaning. A configuration region outside captured RAM would also deliver the record before the first vCPU runs, but would change the machine contract; nvx-rs: replace activation RPC delivery with an uncaptured VMM configuration region nvx#544 measures the packet's cost per four-byte read on KVM, MSHV, and WHP, and keeps the packet.
• Compatibility. Every restore without the option produces the same packet as before, and the snapshot format is unchanged.
• Tests. golden_packet_with_an_activation_record and activation_records_are_bounded encode and decode records of 3 and 1024 bytes, and refuse lengths of 0, 1025, and u32::MAX, packets that end within the length or before or after the record, and the flag's absence; decode_rejects_malformed_packets now refuses bits 6 and 7, since bit 5 is defined. a_restore_packet_carries_an_activation_record serves a 1021-byte record through portb whose last four-byte read takes one byte. The command line's and the RPC's tests cover the option's requirements and its conversion, only_a_platform_restore_hands_over_an_activation_record the tier check, activation_records_hold_one_to_the_most_bytes the file's bounds, and time_abi_restore_packet_carries_the_controller_fields the packet's field.
• Guide. The user guide's restore packet describes flag bit 5 and the record's layout, the CLI reference the option, and the gRPC reference the field.

Validation: cargo clippy --all-targets, cargo doc --no-deps, and cargo nextest run --profile agent of chipset_resources, chipset, openvmm_entry, and openvmm_helpers pass on Windows (522 tests) and on Linux (Azure Linux 3.0, 554 tests), and cargo xtask fmt --fix is clean. NVX's restore scenarios passed on KVM, MSHV, and WHP with this commit and with 2a061ea61, its patch-identical predecessor on ed8fc0713, which NVX's measurements of the record's cost used. On KVM, a platform restore that hands a 64-byte record to a guest that predates the flag fails closed (G_REPAIR_PACKET, restore packet flags 0x24 set reserved bits), and one without a record reaches its marker.