Codestin Search App

amphi · 2026-05-21T08:19:05Z

Summary

Add post-migration network announcements for virtio-net devices so migrated guests
refresh their L2 state on the new host more quickly.

In our tests, connectivity after live migration can take up to 20 seconds
to recover before the VM becomes pingable again. With the post-migration
announcements, the network path is refreshed within a few milliseconds.

The new flow does two things after incoming migration:

sends a host-side RARP on supported virtio-net devices
triggers guest-visible re-announcement when VIRTIO_NET_F_GUEST_ANNOUNCE was negotiated

This is implemented for both virtio-net and vhost-user-net, with VMM hooks to
run the announcement sequence after the destination VM resumes.

Details

Add a post_migration_announce hook to virtio devices and wire it through the VMM
Implement post-migration announcement handling for virtio-net and vhost-user-net
Retry announcements for a short window after migration
Invalidate stale announcers when the device is reset, paused, or starts a new migration
Fix the virtio-net control queue parser to accept VIRTIO_NET_CTRL_ANNOUNCE_ACK
without a data descriptor
Add unit tests for the ACK parser case and announcer invalidation
Update live migration documentation

Open Questions

The post-migration announcers only fire if the VM was not paused prior to the migration, and there is currently no way to trigger the announcers using the API. Is this fine, or do we either
- add an API endpoint to run the announcers (we did that in our fork: Add API call for RARP announcements cyberus-technology/cloud-hypervisor#126)
- trigger the announcements on a paused VM (This would run the RARP announcements immediately, and the guest-visible announcements when the VM resumes)

phip1611

Great work! 🚀 Left a few comments.

PS: If I'm not mistaken, this introduces VMM-driven RARP-packages and guest-driven GARP packages, yes? I think the latter is not entirely clear from the description IMHO

phip1611 · 2026-05-21T14:23:44Z

+    avail_features: u64,
+    acked_features: u64,
+    config: VirtioNetConfig,
+    queue_sizes: Vec<u16>,


while on it: I think you could refactor this easily to Box<[u16]>. This makes clear that this data structure does not resize once constructed. I just tried it locally and it is pretty forward. This would nicely align with changes such as #8231

VirtioCommon uses Vec<u16> for queue_sizes too, I don't think we gain a lot by changing it here but not in VirtioCommon. I think this should be done in one PR.

thanks for the clarification

rbradford

Why do we need this in CH?

rbradford · 2026-05-22T10:24:47Z

+        let _ = thread::Builder::new()
+            .name("post-migration-announcers".to_string())
+            .spawn(move || {
+                for round in 0..rounds {
+                    info!("Post migration announce (async): {}/{}", round + 1, rounds);
+
+                    // The first announcement already was done synchronously, thus
+                    // we sleep at the start of the loop.
+
+                    let delay = (initial_delay + step_delay.saturating_mul(round)).min(max_delay);
+                    debug!("Sleeping {}ms", delay.as_millis());
+                    thread::sleep(delay);
+
+                    announcers.iter_mut().for_each(|a| a.announce());
+                }
+            });


You can't just spin up threads and not track them - they need to exit on exit_evt - need join, etc. Is all this even necessary - I thought if you used libvirt it handles the TAP creation so why are you doing this in CH?

I added life cycle management, please take another look.

rbradford · 2026-05-22T10:26:02Z

+                match unsafe {
+                    libc::write(
+                        tap.as_raw_fd(),
+                        buf.as_ptr() as *const libc::c_void,
+                        buf.len(),
+                    )


The tap implements Write so you don't need this unsafe libc

Good catch, I am using the taps Write now.

amphi · 2026-05-26T07:46:21Z

Why do we need this in CH?

The motivation is to reduce the post-migration connectivity gap. In our tests, after live migration the guest sometimes only became reachable again after several seconds, in the worst case around 20s. With post-migration announcements, the network path was refreshed within a few milliseconds. So the goal is to make network connectivity recover promptly after migration.

I think Cloud Hypervisor is the right layer to trigger this for two reasons:

The VMM knows the precise point at which the destination VM has resumed and the migrated virtio-net device is active again. Management software can observe that migration completed, but it does not necessarily know the exact device-level point where an announcement is both useful and safe.
The required mechanisms are device-internal. For the guest-side path, Cloud Hypervisor has to set VIRTIO_NET_S_ANNOUNCE, inject the virtio config interrupt, and handle VIRTIO_NET_CTRL_ANNOUNCE_ACK. Management software normally does not have direct access to those virtio-net internals.

There is also a practical split of responsibility here: management software can orchestrate migration, but the hypervisor owns the emulated device state and the post-resume device semantics. Implementing this in every management stack would duplicate hypervisor/device-specific knowledge and would still require a VMM-specific API for operations such as triggering the virtio config interrupt.

The host-side RARP and the guest-side VIRTIO_NET_S_ANNOUNCE path also complement each other. RARP can refresh switch MAC learning for the visible guest MAC, while the guest-side announcement lets the guest emit the protocol-specific gratuitous packets it knows how to produce, for example for VLANs or other guest network configuration that the VMM should not try to infer.

This also matches existing hypervisor behavior. QEMU handles virtio-net guest announcements from the VMM/device side after migration, rather than relying purely on management software.

So my view is that Cloud Hypervisor should provide the automatic post-migration announcement behavior as part of virtio-net migration handling. A management API to manually trigger announcements could still be useful as an additional control surface, but it should not be the only mechanism required for the normal live-migration path.

rbradford · 2026-05-29T11:50:10Z

I think PR still has planned changes?

amphi · 2026-05-29T11:58:09Z

I think PR still has planned changes?

Yes, I just pushed some changes. It took me a while to get the life cycle management of the new thread right.

rbradford · 2026-05-29T15:13:28Z

+    /// Tracks whether the guest still needs to acknowledge a post-migration
+    /// announce request through the control queue.


I think this comment is not needed - this member has a really nice clear name.

rbradford · 2026-05-29T15:14:43Z

    avail_features: u64,
    acked_features: u64,
    config: VirtioNetConfig,
+    announce_pending: bool,


I think you need to add #[serde(default)]

rbradford · 2026-05-29T15:16:22Z

+    /// Tracks whether the guest still needs to acknowledge a post-migration
+    /// announce request through the control queue.


Ditto - this member as a clear name.

rbradford · 2026-05-29T15:18:36Z


+/// Constructor-time copy of the fields needed to initialize the live device


Why is "Constructor-time" hyphenated and what does that even mean? I hate this refactoring. It makes it hard to read the code and we don't use this pattern anywhere else in the project.

The reason for this refactoring was reviewability. In our downstream branch, adding the announce-related state directly to the existing constructor caused a lot of surrounding code movement, which made the functional change harder to review.

That said, I understand the concern about introducing a pattern that is not used elsewhere in the project. I do not feel strongly about keeping this refactoring in the upstream PR, so I will remove it and fold the required changes back into the existing structure.

rbradford · 2026-05-29T15:19:16Z

+        offload_tso: bool,
+        offload_ufo: bool,
+        offload_csum: bool,


A good refactoring would be to create a NetOffloadControl struct holding these.

The refactoring here was only meant to reduce review noise for this PR by keeping the functional changes more localized.

I do not intend to include additional unrelated refactorings.

rbradford · 2026-05-29T15:19:38Z

+        if offload_csum {
+            avail_features |= (1 << VIRTIO_NET_F_CSUM)
+                | (1 << VIRTIO_NET_F_GUEST_CSUM)
+                | (1 << VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
+
+            if offload_tso {
+                avail_features |= (1 << VIRTIO_NET_F_HOST_ECN)
+                    | (1 << VIRTIO_NET_F_HOST_TSO4)
+                    | (1 << VIRTIO_NET_F_HOST_TSO6)
+                    | (1 << VIRTIO_NET_F_GUEST_ECN)
+                    | (1 << VIRTIO_NET_F_GUEST_TSO4)
+                    | (1 << VIRTIO_NET_F_GUEST_TSO6);
+            }
+
+            if offload_ufo {
+                avail_features |= (1 << VIRTIO_NET_F_HOST_UFO) | (1 << VIRTIO_NET_F_GUEST_UFO);
+            }
+        }


You could then turn that struct into features via a method on it.

rbradford · 2026-05-29T15:23:36Z

 pub struct CtrlQueue {
    pub taps: Vec<Tap>,
+    /// Tracks whether the guest still needs to acknowledge a post-migration
+    /// announce request through the control queue.


rbradford · 2026-05-29T15:26:25Z

+    exit_evt: EventFd,
+}
+
+impl PostMigrationAnnouncerTask {


This is all way too complicated and overengineered. Can't you just handle it in the virtio-net thread in the destination VM. You know if you've been migrated or restored as it will come through the construction with a State struct.

This does not work.

At that point the device object is being created, but the destination VM has not necessarily resumed yet and the datapath is not necessarily at the point where an announcement can refresh the external network state. The announcement needs to happen after incoming migration, once the migrated device is active on the destination side.

We also observed that a single announcement is not always sufficient. In our downstream setup we repeat the announcements for a short window after migration, and we even added a REST API endpoint to trigger them manually a few seconds after migration completed. That was useful in practice because the timing depends not only on the device construction, but also on when the VM, guest networking, tap/bridge setup, and surrounding network have actually settled.

So I would prefer to keep the trigger tied to the post-migration/resume path rather than the constructor. I can change the implementation if you have any suggestions, but I do not think moving the announcement request into construction would preserve the behavior we need.

The announcement needs to happen after incoming migration, once the migrated device is active on the destination side.

A little more specific:

The announcement needs to happen after a successfully resumed VM (coming from an incoming migration). Otherwise the network's routing information could be in a weird state if the migration failed and keeps running on the source but the "network announcements" happened already on the destination.

The virtio-net epoll thread is only running once the VM is resumed. Put a timerfd into the epoll to handle the periodic notifications.

I'll try that.

@rbradford I moved the retry logic into the epoll thread.

rbradford · 2026-06-03T13:12:57Z

                    );
+
+                    // Advertise new VM location to network switches.
+                    vm.trigger_post_migration_announcements();


Can you explain why you can't just do this on resume? This announcement functionality make sense on snapshot restore (which is a kind of offline migration)

You can avoid doing it on a resume without restore or migration by only enabling it if the Net was constructed with a State.

I see where this idea comes from and it would be great to also have that functionality for snapshot/restore (cold migration). I do have one concern: I'm afraid that doing this in Vm::resume() might cause network weirdness when we just did pause/resume() on the same host - which is valid behavior.

a.) I don't think the RARP requests should do that
b.) That's why I said it can be easily gated on if the Net was instatiated with a State struct or not - it won't be if it's just a pause-resume on the same host but it will be for restore or live migration.

I would rather use the signals we already have rather than add code.

Ah okay! I agree with you, makes sense. This is a cleaner design!

We might need vm.trigger_post_migration_announcements() in a dedicated endpoint as well but this is an orthogonal discussion and a dedicated PR. I'm not the expert there but @amphi is.

@amphi you plan to do this in a follow-up I guess, yeah?

Please can we fix this in this PR.

But we only know whether it was instantiated with a State struct or not in the constructor, right? We don't store this information for later. But at this point we cannot run the announcers (maybe we can run the RARP announcer, but for the guest announcement we need the interrupt_cb, which I think is installed during activation).

We could set announce_pending in the constructor if the device was instantiated from a State, and then during activation check whether we have to do announcements.

Is this what you have envisioned?

Adding the endpoint later would still be easy enough.

Right - I was leaving that detail to you:

If you put these: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/8263/changes#diff-871d3317222951a9828d52adbf479d80ad1d43c3f192a186d65ea445502a833bR477-R483 into a struct - you can then put it into an Option<..> and set it only when it's been restored or however you see fit.

I made the changes necessary to always do announcements if the device was constructed from a State.

rbradford · 2026-06-08T10:57:05Z

+    /// Return the guest-visible virtio-net config, recomputing `status` from the
+    /// current state of the device.
+    fn config_with_status(&self) -> VirtioNetConfig {
+        let mut config = self.config;
+
+        // We want to recompute the guest-visible status field from the current state of
+        // the device. We clear this field first to avoid showing stale data.
+        config.status = 0;
+
+        if self
+            .vu_common
+            .virtio_common
+            .feature_acked(VIRTIO_NET_F_STATUS.into())
+        {
+            config.status |= VIRTIO_NET_S_LINK_UP as u16;
+
+            if self.announce_pending.load(Ordering::Acquire) {
+                config.status |= VIRTIO_NET_S_ANNOUNCE as u16;
+            }
+        }
+
+        config
+    }


Would't it be cleaner to ensure that self.config was correct at all points in time. Rather than just updating a copy of it here when capturing the state?

Since we only really use it here, I see no value in adding the code to every path that may or may not change it to be honest.

Then do it as a update method that modifies it in place or construct it on demand. Don't take what's there, modify it and then derive from it. That's just confusing.

I changed this to construct the returned config more directly.

rbradford

Is it possible to refactor so that more code is shared between virtio-net and vhost-user-net?

amphi · 2026-06-08T13:04:23Z

Is it possible to refactor so that more code is shared between virtio-net and vhost-user-net?

I don't think there is a lot of code that can be shared, partly due to the subtle differences between virtio-net and vhost-user-net (e.g. self.common.feature_acked vs self.vu_common.virtio_common.feature_acked). There are really small parts that could be shared, but this would require introducing an extra layer of abstractions, which makes the code more confusing to read.

Thus I don't think there are any sensible refactors to share more code between virtio-net and vhost-user-net.

phip1611 · 2026-06-09T13:13:27Z

+    Done,
+}
+
+/// [`NetCtrlEpollHandler`] is shared between virtio-net and vhost-user-net, but


I think this comment doesn't really hit the right tone. This sounds like the why part which is very unusual as the first sentence for rustdoc of a type.

rbradford

I think this is suffering a little bit from too many comments hiding what is important. Can you take a critical eye over this to make sure it's as a minimal as possible

rbradford · 2026-06-09T15:53:59Z


-fn vnet_hdr_len() -> usize {
+/// Returns the virtio-net header size configured on TAP file descriptors.
+///


I think comment is excessive

rbradford · 2026-06-09T15:56:38Z

+        let (avail_features, acked_features, config, queue_sizes, paused, announce_pending) =
+            if let Some(state) = state {
+                info!("Restoring virtio-net {id}");
+                // Always set [`Self::announce_pending`] to true if the device was restored to
+                // make sure the device announces itself.
+                (
+                    state.avail_features,
+                    state.acked_features,
+                    state.config,
+                    state.queue_size,
+                    true,
+                    true,
+                )
+            } else {
+                let mut avail_features = (1 << VIRTIO_RING_F_EVENT_IDX) | (1 << VIRTIO_F_VERSION_1);

-            if access_platform_enabled {
-                avail_features |= 1u64 << VIRTIO_F_ACCESS_PLATFORM;
-            }
+                if mtu.is_some() {
+                    avail_features |= 1 << VIRTIO_NET_F_MTU;
+                }

-            // Configure TSO/UFO features when hardware checksum offload is enabled.
-            if offload_csum {
-                avail_features |= (1 << VIRTIO_NET_F_CSUM)
-                    | (1 << VIRTIO_NET_F_GUEST_CSUM)
-                    | (1 << VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
-
-                if offload_tso {
-                    avail_features |= (1 << VIRTIO_NET_F_HOST_ECN)
-                        | (1 << VIRTIO_NET_F_HOST_TSO4)
-                        | (1 << VIRTIO_NET_F_HOST_TSO6)
-                        | (1 << VIRTIO_NET_F_GUEST_ECN)
-                        | (1 << VIRTIO_NET_F_GUEST_TSO4)
-                        | (1 << VIRTIO_NET_F_GUEST_TSO6);
+                if access_platform_enabled {
+                    avail_features |= 1u64 << VIRTIO_F_ACCESS_PLATFORM;
                }

-                if offload_ufo {
-                    avail_features |= (1 << VIRTIO_NET_F_HOST_UFO) | (1 << VIRTIO_NET_F_GUEST_UFO);
+                // Configure TSO/UFO features when hardware checksum offload is enabled.
+                if offload_csum {
+                    avail_features |= (1 << VIRTIO_NET_F_CSUM)
+                        | (1 << VIRTIO_NET_F_GUEST_CSUM)
+                        | (1 << VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
+
+                    if offload_tso {
+                        avail_features |= (1 << VIRTIO_NET_F_HOST_ECN)
+                            | (1 << VIRTIO_NET_F_HOST_TSO4)
+                            | (1 << VIRTIO_NET_F_HOST_TSO6)
+                            | (1 << VIRTIO_NET_F_GUEST_ECN)
+                            | (1 << VIRTIO_NET_F_GUEST_TSO4)
+                            | (1 << VIRTIO_NET_F_GUEST_TSO6);
+                    }
+
+                    if offload_ufo {
+                        avail_features |=
+                            (1 << VIRTIO_NET_F_HOST_UFO) | (1 << VIRTIO_NET_F_GUEST_UFO);
+                    }
                }
-            }

-            avail_features |= 1 << VIRTIO_NET_F_CTRL_VQ;
-            let queue_num = num_queues + 1;
+                avail_features |= 1 << VIRTIO_NET_F_CTRL_VQ;
+                avail_features |= 1 << VIRTIO_NET_F_STATUS;
+                let queue_num = num_queues + 1;



Why are there so many lines changed here?

I added announce_pending in line 527, that made the line break, and that made many lines shift to the right. In our fork, we added a refactor first, so it was easier to see what really changed. This is was the refactor that you didn't like and that I reverted.

rbradford · 2026-06-10T14:41:33Z

+        (libc::SYS_socket, vec![]),
+        (libc::SYS_getsockname, vec![]),
+        (libc::SYS_timerfd_settime, vec![]),
+        (libc::SYS_ioctl, create_virtio_net_ctl_ioctl_seccomp_rule()),


These should be in alphabetical order like the rest of the file.

rbradford

I think this is looking a lot cleaner now - thanks for the iterations!

rbradford · 2026-06-20T09:25:29Z

+        (libc::SYS_ioctl, create_virtio_net_ctl_ioctl_seccomp_rule()),
+        (libc::SYS_socket, vec![]),
+        (libc::SYS_timerfd_settime, vec![]),
+        (libc::SYS_write, vec![]),


SYS_write Already included in common

Yeah that was a debugging leftover, I removed it.

rbradford · 2026-06-20T09:26:09Z

 fn virtio_net_ctl_thread_rules() -> Vec<(i64, Vec<SeccompRule>)> {
-    vec![(libc::SYS_ioctl, create_virtio_net_ctl_ioctl_seccomp_rule())]
+    vec![
+        (libc::SYS_getsockname, vec![]),


Is this actually needed?

Debugging leftover, I removed it.

rbradford · 2026-06-20T09:26:14Z

+    vec![
+        (libc::SYS_getsockname, vec![]),
+        (libc::SYS_ioctl, create_virtio_net_ctl_ioctl_seccomp_rule()),
+        (libc::SYS_socket, vec![]),


Debugging leftover, I removed it.

rbradford · 2026-06-20T09:26:48Z

@@ -186,7 +186,13 @@ fn create_virtio_net_ctl_ioctl_seccomp_rule() -> Vec<SeccompRule> {
 }

 fn virtio_net_ctl_thread_rules() -> Vec<(i64, Vec<SeccompRule>)> {


The syscall changes should be folded into the commit that needs them to make it bisectable.

rbradford · 2026-06-20T09:30:23Z

+    /// When signaled, the epoll thread will do the post-migration
+    /// announcements.
+    announce_evt: EventFd,


It's not just about migration - it triggers on restore from a snapshot too. Please cleanup your comments/commit messages etc to cover the broader restore case.

To be clear, in case I was not, you should make sure this functionality works correctly for restore from a snapshot too (offline migration).

I changed the commit messages and comments so it now states that these are post-migration and post-restore announcers.

rbradford · 2026-06-20T09:37:45Z

            if let Some(state) = state {
                info!("Restoring virtio-net {id}");
+                // Always set [`Self::announce_pending`] to true if the device was restored to
+                // make sure the device announces itself.


If you're always going to set this to true - why bother storing it?

This is not always true. It is set to true only for the restore-from-state path, where we need a pending post-migration announcement.

For the normal fresh-device path it remains false.

So the field tracks transient pending work: whether this device still needs to announce itself after restore. I can make that clearer by deriving the initial value from state.is_some() before consuming the restored NetState.

What i'm saying is why store it in the NetState if you are always going to set it.

rbradford · 2026-06-20T09:42:57Z

+    fn send_guest_announce(&mut self) -> AnnounceOutcome {
+        if !self.guest_announce_negotiated {
+            // [`Net::announce_pending`] does double duty: we use it to signal that the
+            // driver in the guest has to send announcements, but we also use it to signal
+            // that the device has been constructed from a `State` (e.g. after a
+            // live-migration or during snapshot restore). Thus, it may happen that
+            // VIRTIO_NET_F_GUEST_ANNOUNCE was not negotiated, but [`Net::announce_pending`]
+            // is set. In this case, we just clear it here.
+            self.announce_pending.store(false, Ordering::Release);
+            return AnnounceOutcome::Done;
+        }
+
+        // If the guest hasn't ack'ed the announce, we trigger the interrupt.
+        if self.announce_pending.load(Ordering::Acquire) {
+            self.interrupt_cb
+                .trigger(VirtioInterruptType::Config)
+                .inspect_err(|e| {
+                    warn!("Unable to send interrupt for virtio-net device: {e}");
+                })
+                .ok();
+
+            // We have to check again whether the driver ack'ed the announcement.
+            return AnnounceOutcome::Retry;
+        }
+        AnnounceOutcome::Done
+    }


QEMU limits it to 3 notifications (in case the guest never ACKs it) we should do something similar otherwise we're going to keep interrupting.

By default Qemu does it five times (see https://github.com/qemu/qemu/blob/master/migration/options.c#L81), and I am doing the same now.

rbradford · 2026-06-22T09:42:54Z

+    #[serde(default)]
+    pub announce_pending: bool,


Ah yeah right, that is obsolete now.

rbradford · 2026-06-22T09:43:29Z

            if let Some(state) = state {
                info!("Restoring virtio-net {id}");
+                // Always set [`Self::announce_pending`] to true if the device was restored to
+                // make sure the device announces itself.


What i'm saying is why store it in the NetState if you are always going to set it.

rbradford · 2026-07-01T06:23:25Z

@amphi Needs a rebase

Expose `VIRTIO_NET_S_LINK_UP` through the virtio-net config status field when `VIRTIO_NET_F_STATUS` was negotiated. This makes the guest-visible status bits reflect the device runtime state and prepares the config status path used by later post-migration announce handling. On-behalf-of: SAP [email protected] Signed-off-by: Sebastian Eydam <[email protected]>

amphi · 2026-07-01T08:24:44Z

@rbradford I just rebased.

rbradford

Could you try and reduce the duplication?

rbradford · 2026-07-01T17:34:48Z

+
+impl AnnounceOps for VhostUserNetAnnounceOps {
+    fn initialize(&mut self) {
+        self.generation = self.announce_generation.load(Ordering::Acquire);


In the virtio-net version you set announcements_done to 0 here.

This struct is gone now.

rbradford · 2026-07-01T17:37:33Z

+    pub interrupt_cb: Arc<dyn VirtioInterrupt>,
+    pub guest_announce_negotiated: bool,
+    pub announce_pending: Arc<AtomicBool>,
+    pub announce_generation: Arc<AtomicU64>,
+    pub generation: u64,


Do these need to be pub?

This struct is gone now.

rbradford · 2026-07-01T17:40:44Z

+                    state.config,
+                    state.queue_size,
+                    true,
+                    true,


In vhost-user-net announce_pending is gated on VIRTIO_NET_F_GUEST_ANNOUNCE being acked.

Yes, but for virtio-net we can also just do the host-side RARP announcements. So we unconditionally set this to true and check later which announcements can be done.

rbradford · 2026-07-01T17:42:05Z

+When the restored VM resumes, Cloud Hypervisor asks supported network devices
+to re-announce the VM on the network. For `virtio-net`, the current
+implementation sets `VIRTIO_NET_S_ANNOUNCE`, raises a config interrupt,
+retries that request a few times in the background, and also sends host-side
+RARP announcements on the TAP interfaces. A guest re-announcement therefore
+only happens when the guest negotiated `VIRTIO_NET_F_GUEST_ANNOUNCE`. For
+`vhost-user-net`, the current implementation only uses the guest announcement
+path.


This paragraph is duplicated everywhere - just add a section about announcement to live migration and reference it.

rbradford · 2026-07-01T18:11:02Z

@amphi I asked Claude to give consolidating it a go: main...rbradford:cloud-hypervisor:202607/virtio-net-consolidated net 300 fewer lines.

Advertise `VIRTIO_NET_F_GUEST_ANNOUNCE` on virtio-net devices, surface `VIRTIO_NET_S_ANNOUNCE` through config status, and handle `VIRTIO_NET_CTRL_ANNOUNCE_ACK` on the control queue. This adds the guest-visible state needed for post-migration or post-restore announce requests; the VMM side triggering is added in follow-up commits. The motivation is to reduce post-migration and post-restore connectivity gap. After a live migration or after restoring, it can take the guest several seconds to be reachable again over the network. With these announcements, the network path should be refreshed within a few milliseconds. On-behalf-of: SAP [email protected] Signed-off-by: Sebastian Eydam <[email protected]>

amphi · 2026-07-02T11:50:23Z

@amphi I asked Claude to give consolidating it a go: main...rbradford:cloud-hypervisor:202607/virtio-net-consolidated net 300 fewer lines.

I took inspiration from that branch and applied the changes I deemed sensible. E.g. moving status_bits into GuestAnnounce doesn't seem like a very clean abstraction to me.

There are a few less LOC now.

rbradford

lgtm - thanks for the patience on the interations!

phip1611 · 2026-07-02T18:16:00Z

Awesome to have that! Thanks everyone for patience, review, testing and engineering!

Our Cyberus Technology patchset is getting shorter and shorter 🚀

amphi requested a review from a team as a code owner May 21, 2026 08:19

phip1611 reviewed May 21, 2026

View reviewed changes

likebreath self-requested a review May 22, 2026 00:52

rbradford requested changes May 22, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch 2 times, most recently from 1cc9ec7 to 10fcd29 Compare May 29, 2026 11:57

rbradford requested changes May 29, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch 2 times, most recently from b0eff3a to 94023cb Compare June 3, 2026 11:06

rbradford requested changes Jun 3, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch 2 times, most recently from 8e5c605 to aacd77c Compare June 8, 2026 09:32

amphi requested a review from rbradford June 8, 2026 09:41

amphi force-pushed the upstream-virtio-net-announcements branch from aacd77c to fd3d8e4 Compare June 8, 2026 10:51

rbradford reviewed Jun 8, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch from fd3d8e4 to c0942ec Compare June 8, 2026 12:39

rbradford reviewed Jun 8, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch from c0942ec to ab9bf51 Compare June 9, 2026 07:38

phip1611 reviewed Jun 9, 2026

View reviewed changes

rbradford requested changes Jun 9, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch 3 times, most recently from df28237 to 707e908 Compare June 10, 2026 11:21

rbradford reviewed Jun 10, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch from 707e908 to 6ba7725 Compare June 10, 2026 16:37

rbradford marked this pull request as draft June 12, 2026 11:31

amphi force-pushed the upstream-virtio-net-announcements branch 4 times, most recently from 6e8c44c to 04134c2 Compare June 19, 2026 19:48

rbradford reviewed Jun 20, 2026

View reviewed changes

rbradford reviewed Jun 22, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch 3 times, most recently from 4cd5c94 to 6e2b233 Compare June 22, 2026 12:32

amphi marked this pull request as ready for review June 22, 2026 13:49

phip1611 mentioned this pull request Jun 23, 2026

Live Migration Feature Tracking and Collaboration #7111

Open

amphi requested a review from rbradford June 24, 2026 09:11

amphi force-pushed the upstream-virtio-net-announcements branch from 6e2b233 to 18e7816 Compare July 1, 2026 08:16

rbradford requested changes Jul 1, 2026

View reviewed changes

amphi force-pushed the upstream-virtio-net-announcements branch from 18e7816 to 629155a Compare July 2, 2026 11:45

rbradford approved these changes Jul 2, 2026

View reviewed changes

rbradford added this pull request to the merge queue Jul 2, 2026

Merged via the queue into cloud-hypervisor:main with commit 53a00c0 Jul 2, 2026
39 checks passed

amphi mentioned this pull request Jul 3, 2026

virtio-devices: net: offer VIRTIO_NET_F_GUEST_ANNOUNCE to guests #8521

Merged

rbradford added this to Cloud Hypervisor Roadmap Jul 8, 2026

github-project-automation Bot moved this to ✅ Done in Cloud Hypervisor Roadmap Jul 8, 2026

rbradford added the new-feature New feature to include in release notes label Jul 10, 2026

		/// Tracks whether the guest still needs to acknowledge a post-migration
		/// announce request through the control queue.


		/// Constructor-time copy of the fields needed to initialize the live device

		@@ -186,7 +186,13 @@ fn create_virtio_net_ctl_ioctl_seccomp_rule() -> Vec<SeccompRule> {
		}

		fn virtio_net_ctl_thread_rules() -> Vec<(i64, Vec<SeccompRule>)> {

Uh oh!

Conversation

amphi commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details

Open Questions

Uh oh!

phip1611 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amphi May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rbradford left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amphi commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rbradford commented May 29, 2026

Uh oh!

amphi commented May 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phip1611 Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rbradford Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amphi commented May 21, 2026 •

edited

Loading

amphi May 29, 2026 •

edited

Loading

amphi commented May 26, 2026 •

edited

Loading

phip1611 Jun 1, 2026 •

edited

Loading

rbradford Jun 1, 2026 •

edited

Loading

phip1611 Jun 3, 2026 •

edited

Loading