From: Markus Hennecke <markus-hennecke@markus-hennecke.de>
Subject: hvs no longer attaches in Hyper-V guest
To: tech@openbsd.org
Date: Fri, 18 Sep 2026 18:19:06 +0200

Last week I got a report about a system in the Azure cloud failing fsck 
after a reboot. It turned out the machine had lost all SCSI disks and 
booted only from the emulated IDE controller's OS disk. Unfortunately only 
the first disk is accessible via the emulated IDE controller, so the other 
disks were missing resulting in the fsck error on boot.

I found this recent question which describes the same behaviour of 
OpenBSD on Azure: 
https://learn.microsoft.com/en-my/answers/questions/5986420/azure-vm-bios-version-changed-after-reboot-openbsd

I reproduced the problem using Hyper-V on a Windows 11 host. Disks no 
longer attach via the hvs driver. The machine on the Windows 11 host shows 
the same bios date as the VM on Azure.

It appears current Hyper-V hosts no longer set the 
VMBUS_CHOFFER_FLAG1_HASMNF bit in chm_flags1 for ide and scsi channel 
offers. As a result CHF_MONITOR is never set for these channels, and 
hv_attach_devices() skips them, so config_found() is never called.

The patch below adds a new CHF_SIGNAL flag, set in hv_process_offer() 
specifically when the channel's ch_ident is "ide" or "scsi", and has 
hv_attach_devices() proceed if either CHF_MONITOR or CHF_SIGNAL is set. 
This leaves the monitor-flag check unchanged for all other channel types 
and only adds the storage channels as an explicit exception.

This should be safe because hvs communicates with the hypervisor via 
hypercalls rather than relying on the monitor/notification mechanism, so 
the monitor bit isn't actually needed for it to function.

With the patch applied, hvs devices attach and the disks shows up 
correctly on an affected Hyper-V (Windows 11) host. My test system 
survived a full release build.

We moved the system away from Azure, to get it up and running again fast. 
So right now I can't test the fix on Azure.

Regards
Markus 

Index: hyperv.c
===================================================================
RCS file: /cvs/src/sys/dev/pv/hyperv.c,v
retrieving revision 1.53
diff -u -p -u -r1.53 hyperv.c
--- hyperv.c	24 May 2024 10:05:55 -0000	1.53
+++ hyperv.c	15 Sep 2026 11:17:57 -0000
@@ -1061,6 +1061,8 @@ hv_process_offer(struct hv_softc *sc, st
 		nch->ch_mindex = co->co_chan.chm_montrig % VMBUS_MONTRIG_LEN;
 		nch->ch_flags |= CHF_MONITOR;
 	}
+	if (!(strcmp("ide", nch->ch_ident) && strcmp("scsi", nch->ch_ident)))
+		nch->ch_flags |= CHF_SIGNAL;
 
 	nch->ch_id = co->co_chan.chm_chanid;
 
@@ -1806,7 +1808,7 @@ hv_attach_devices(struct hv_softc *sc)
 	TAILQ_FOREACH(ch, &sc->sc_channels, ch_entry) {
 		if (ch->ch_state != HV_CHANSTATE_OFFERED)
 			continue;
-		if (!(ch->ch_flags & CHF_MONITOR))
+		if (!(ch->ch_flags & (CHF_MONITOR | CHF_SIGNAL)))
 			continue;
 		dv = malloc(sizeof(*dv), M_DEVBUF, M_ZERO | M_NOWAIT);
 		if (dv == NULL) {
Index: hypervvar.h
===================================================================
RCS file: /cvs/src/sys/dev/pv/hypervvar.h,v
retrieving revision 1.13
diff -u -p -u -r1.13 hypervvar.h
--- hypervvar.h	23 Jun 2017 19:05:42 -0000	1.13
+++ hypervvar.h	15 Sep 2026 11:17:57 -0000
@@ -86,6 +86,7 @@ struct hv_channel {
 	uint32_t			 ch_flags;
 #define  CHF_BATCHED			  0x0001
 #define  CHF_MONITOR			  0x0002
+#define  CHF_SIGNAL			  0x0004
 
 	uint8_t				 ch_mgroup;
 	uint8_t				 ch_mindex;