On Wed, Jan 28, 2026 at 12:22 AM David Woodhouse <[email protected]> wrote:
>
> >
>
> I think 'kp' leaks in the error case there? And the next one in
> assign_kernel_eventfd().
>
> I don't much like duplicating the code which performs the ioctls.
> Couldn't you have a helper function which does that when given a
> 'struct kernel_ports', then invoke *that* from both places?
>
> Or even better, make use of the fact that we *already* have the ability
> to replay these for serialisation/deserialisation?
>
> But backing up a little more... if this is for rebooting guests,
> shouldn't we be wiping the event channel setup completely, like a soft
> reset? Do we preserve to do *any* of this? Are you sure you don't see a
> soft reset wiping it all away, either before or after this code runs?
Ah yes, good catch! I added the following assertions and they never
failed has I walked through the code with gdb:
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 7802fa68ae..3c882d85bb 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -1241,6 +1241,9 @@ int xen_evtchn_soft_reset(void)
kvm_update_msi_routes_all(NULL, true, 0, 0);
}
+ assert(QLIST_EMPTY(&eventfd_list));
+ assert(QLIST_EMPTY(&kernel_port_list));
+
return 0;
}
I reverted this patch and it does not break my Xen functional test. So
it seems the soft reset calls
xen_evtchn_soft_reset() -> close_port() -> deassign_kernel_port() and
all ports are cleaned up, meaning they do not need preserving through
the reset.
I will drop this patch in the next spin-up.
