On confidential guests when the KVM virtual machine file descriptor changes as
a part of the reset process, event file descriptors needs to be reassociated
with the new KVM VM file descriptor. This is achieved with the help of a
callback handler that gets called when KVM VM file descriptor changes during
the confidential guest reset process.

Signed-off-by: Ani Sinha <anisinha@redhat.com>
---
 hw/hyperv/vmbus.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.c
index 961406cdd6..4763c0aebc 100644
--- a/hw/hyperv/vmbus.c
+++ b/hw/hyperv/vmbus.c
@@ -19,6 +19,7 @@
 #include "hw/hyperv/vmbus.h"
 #include "hw/hyperv/vmbus-bridge.h"
 #include "hw/sysbus.h"
+#include "system/kvm.h"
 #include "exec/target_page.h"
 #include "trace.h"
 
@@ -247,6 +248,12 @@ struct VMBus {
      * interrupt page
      */
     EventNotifier notifier;
+
+    /*
+     * Notifier to inform when vmfd is changed as a part of confidential guest
+     * reset mechanism.
+     */
+    NotifierWithReturn vmbus_vmfd_change_notifier;
 };
 
 static bool gpadl_full(VMBusGpadl *gpadl)
@@ -2346,6 +2353,26 @@ static void vmbus_dev_unrealize(DeviceState *dev)
     free_channels(vdev);
 }
 
+/*
+ * If the KVM fd changes because of VM reset in confidential guests,
+ * reassociate event fd with the new KVM fd.
+ */
+static int vmbus_handle_vmfd_change(NotifierWithReturn *notifier,
+                                    void *data, Error** errp)
+{
+    VMBus *vmbus = container_of(notifier, VMBus,
+                                vmbus_vmfd_change_notifier);
+    int ret = 0;
+    ret = hyperv_set_event_flag_handler(VMBUS_EVENT_CONNECTION_ID,
+                                            &vmbus->notifier);
+    /* if we are only using userland event handler, it may already exist */
+    if (ret != 0 && ret != -EEXIST) {
+        error_setg(errp, "hyperv set event handler failed with %d", ret);
+    }
+
+    return ret;
+}
+
 static const Property vmbus_dev_props[] = {
     DEFINE_PROP_UUID("instanceid", VMBusDevice, instanceid),
 };
@@ -2428,6 +2455,9 @@ static void vmbus_realize(BusState *bus, Error **errp)
         goto clear_event_notifier;
     }
 
+    vmbus->vmbus_vmfd_change_notifier.notify = vmbus_handle_vmfd_change;
+    kvm_vmfd_add_change_notifier(&vmbus->vmbus_vmfd_change_notifier);
+
     return;
 
 clear_event_notifier:
-- 
2.42.0

On 12.12.2025 16:03, Ani Sinha wrote:
> On confidential guests when the KVM virtual machine file descriptor changes as
> a part of the reset process, event file descriptors needs to be reassociated
> with the new KVM VM file descriptor. This is achieved with the help of a
> callback handler that gets called when KVM VM file descriptor changes during
> the confidential guest reset process.
> 
> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> ---

Have you actually tested confidential guests with VMBus or is this a change
"for completeness sake" that can't be exercised in the current state of things?

Thanks,
Maciej

> On 15 Dec 2025, at 10:34 PM, Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote:
> 
> On 12.12.2025 16:03, Ani Sinha wrote:
>> On confidential guests when the KVM virtual machine file descriptor changes as
>> a part of the reset process, event file descriptors needs to be reassociated
>> with the new KVM VM file descriptor. This is achieved with the help of a
>> callback handler that gets called when KVM VM file descriptor changes during
>> the confidential guest reset process.
>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>> ---
> 
> Have you actually tested confidential guests with VMBus or is this a change
> "for completeness sake" that can't be exercised in the current state of things?

No I have not tested the changes with VMBus. It’s more for completeness sake as you have correctly put it. If you suggest, I can drop the change.

On 16.12.2025 05:41, Ani Sinha wrote:
> 
> 
>> On 15 Dec 2025, at 10:34 PM, Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote:
>>
>> On 12.12.2025 16:03, Ani Sinha wrote:
>>> On confidential guests when the KVM virtual machine file descriptor changes as
>>> a part of the reset process, event file descriptors needs to be reassociated
>>> with the new KVM VM file descriptor. This is achieved with the help of a
>>> callback handler that gets called when KVM VM file descriptor changes during
>>> the confidential guest reset process.
>>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>>> ---
>>
>> Have you actually tested confidential guests with VMBus or is this a change
>> "for completeness sake" that can't be exercised in the current state of things?
> 
> No I have not tested the changes with VMBus. It’s more for completeness sake as you have correctly put it. If you suggest, I can drop the change.
> 

I have mixed feelings here: on the one hand this support could be useful in
the future, on the other hand we probably don't want to add dead and
untestable code to QEMU.

Let's see what other maintainers think about adding such code in order to
be consistent across different subsystems.

Thanks,
Maciej

On Tue, Dec 16, 2025 at 02:38:10PM +0100, Maciej S. Szmigiero wrote:
> On 16.12.2025 05:41, Ani Sinha wrote:
> > 
> > 
> > > On 15 Dec 2025, at 10:34 PM, Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote:
> > > 
> > > On 12.12.2025 16:03, Ani Sinha wrote:
> > > > On confidential guests when the KVM virtual machine file descriptor changes as
> > > > a part of the reset process, event file descriptors needs to be reassociated
> > > > with the new KVM VM file descriptor. This is achieved with the help of a
> > > > callback handler that gets called when KVM VM file descriptor changes during
> > > > the confidential guest reset process.
> > > > Signed-off-by: Ani Sinha <anisinha@redhat.com>
> > > > ---
> > > 
> > > Have you actually tested confidential guests with VMBus or is this a change
> > > "for completeness sake" that can't be exercised in the current state of things?
> > 
> > No I have not tested the changes with VMBus. It’s more for completeness sake as you have correctly put it. If you suggest, I can drop the change.
> > 
> 
> I have mixed feelings here: on the one hand this support could be useful in
> the future, on the other hand we probably don't want to add dead and
> untestable code to QEMU.
> 
> Let's see what other maintainers think about adding such code in order to
> be consistent across different subsystems.

In any case the testing status of these changes should be noted in the
commit messages.  There are some xen changes in the series where I
suspect they are untested too ...

take care,
  Gerd

> On 17 Dec 2025, at 7:38 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> On Tue, Dec 16, 2025 at 02:38:10PM +0100, Maciej S. Szmigiero wrote:
>> On 16.12.2025 05:41, Ani Sinha wrote:
>>> 
>>> 
>>>> On 15 Dec 2025, at 10:34 PM, Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote:
>>>> 
>>>> On 12.12.2025 16:03, Ani Sinha wrote:
>>>>> On confidential guests when the KVM virtual machine file descriptor changes as
>>>>> a part of the reset process, event file descriptors needs to be reassociated
>>>>> with the new KVM VM file descriptor. This is achieved with the help of a
>>>>> callback handler that gets called when KVM VM file descriptor changes during
>>>>> the confidential guest reset process.
>>>>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>>>>> ---
>>>> 
>>>> Have you actually tested confidential guests with VMBus or is this a change
>>>> "for completeness sake" that can't be exercised in the current state of things?
>>> 
>>> No I have not tested the changes with VMBus. It’s more for completeness sake as you have correctly put it. If you suggest, I can drop the change.
>>> 
>> 
>> I have mixed feelings here: on the one hand this support could be useful in
>> the future, on the other hand we probably don't want to add dead and
>> untestable code to QEMU.
>> 
>> Let's see what other maintainers think about adding such code in order to
>> be consistent across different subsystems.
> 
> In any case the testing status of these changes should be noted in the
> commit messages.  There are some xen changes in the series where I
> suspect they are untested too ...

Yes all the Xen stuff is untested. I was thinking of dropping those patches but posted them for completeness and suggestion from maintainers. If we think we should drop them, I will be happy to do so.