From 32ea0a33e3a0fb7c10c601b43e1b2f6c06a3f5fd Mon Sep 17 00:00:00 2001 From: Waiman Long Date: Sun, 30 Aug 2026 19:41:24 -0400 Subject: [PATCH 01/11] Drivers: hv: Avoid infinite retry loop in init_vp_index() There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found. Link: https://sashiko.dev/#/message/20260422030903.E1BFCC2BCB0%40smtp.kernel.org [1] Fixes: 6640b5df1a38 ("Drivers: hv: vmbus: Don't assign VMbus channel interrupts to isolated CPUs") Signed-off-by: Waiman Long Reviewed-by: Michael Kelley Signed-off-by: Wei Liu --- drivers/hv/channel_mgmt.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index a044fd3b3c4e..c42def04ac41 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -752,13 +752,14 @@ static void init_vp_index(struct vmbus_channel *channel) u32 i, ncpu = num_online_cpus(); cpumask_var_t available_mask; struct cpumask *allocated_mask; + const struct cpumask *node_mask; const struct cpumask *hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ); u32 target_cpu; int numa_node; if (!perf_chn || !alloc_cpumask_var(&available_mask, GFP_KERNEL) || - cpumask_empty(hk_mask)) { + !cpumask_intersects(hk_mask, cpu_online_mask)) { /* * If the channel is not a performance critical * channel, bind it to VMBUS_CONNECT_CPU. @@ -780,14 +781,19 @@ static void init_vp_index(struct vmbus_channel *channel) next_numa_node_id = 0; continue; } - if (cpumask_empty(cpumask_of_node(numa_node))) + /* + * Try next NUMA node if current NUMA node has no CPU + * or doesn't contain any housekeeping CPU. + */ + node_mask = cpumask_of_node(numa_node); + if (!cpumask_intersects(node_mask, hk_mask)) continue; break; } allocated_mask = &hv_context.hv_numa_map[numa_node]; retry: - cpumask_xor(available_mask, allocated_mask, cpumask_of_node(numa_node)); + cpumask_xor(available_mask, allocated_mask, node_mask); cpumask_and(available_mask, available_mask, hk_mask); if (cpumask_empty(available_mask)) { From 0cdd57a4c56115af5d736b5b2d9310ad91494abc Mon Sep 17 00:00:00 2001 From: Jiangshan Yi Date: Tue, 1 Sep 2026 11:32:01 +0800 Subject: [PATCH 02/11] x86/hyperv: Fix stale comments after stimer message mode removal The removal of stimer message mode in commit be0cfab740e5 ("clocksource: hyper-v: Remove support for stimer interrupts in message mode") left a few comments out of date. hv_stimer_setup_percpu_clockev() picked up two typos ("afters", "to allows"), and the hv_synic_suspend() comment still references the deleted hv_stimer_legacy_cleanup(), the legacy non-Direct Mode configuration, and clockevents_unbind_device(), which is no longer on the cleanup path. Update the typos and rewrite the hv_synic_suspend() comment to describe the current Direct Mode path: non-boot CPU stimers are cleaned up via the cpuhp teardown callback hv_stimer_cleanup(), and CPU0's stimer is left alone because it is harmless (interrupts stay disabled across the suspend/resume window) and is shut down later by the timekeeping code. Signed-off-by: Jiangshan Yi Reviewed-by: Michael Kelley Signed-off-by: Wei Liu --- arch/x86/hyperv/hv_init.c | 4 ++-- drivers/hv/vmbus_drv.c | 18 +++++++----------- 2 files changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 0b4a1c0b0b16..690f95295ee4 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -426,7 +426,7 @@ static void __init hv_stimer_setup_percpu_clockev(void) int ret; /* - * Continue afters errors in setting up stimer clockevents + * Continue after errors in setting up stimer clockevents * as we can run with the LAPIC timer as a fallback. */ ret = hv_stimer_alloc(false); @@ -434,7 +434,7 @@ static void __init hv_stimer_setup_percpu_clockev(void) pr_warn("stimer setup failed with error %d\n", ret); /* - * Still register the LAPIC timer to allows users + * Still register the LAPIC timer to allow users * to switch to LAPIC timer via /sys, if they want to. */ if (old_setup_percpu_clockev) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 5ebdbe24b5a1..c1edc3a5b673 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -2923,23 +2923,19 @@ static void hv_crash_handler(struct pt_regs *regs) static int hv_synic_suspend(void *data) { /* - * When we reach here, all the non-boot CPUs have been offlined. - * If we're in a legacy configuration where stimer Direct Mode is - * not enabled, the stimers on the non-boot CPUs have been unbound - * in hv_synic_cleanup() -> hv_stimer_legacy_cleanup() -> - * hv_stimer_cleanup() -> clockevents_unbind_device(). + * When we reach here, all the non-boot CPUs have been offlined, + * and their stimers have been cleaned up by the cpuhp teardown + * callback hv_stimer_cleanup(). * * hv_synic_suspend() only runs on CPU0 with interrupts disabled. - * Here we do not call hv_stimer_legacy_cleanup() on CPU0 because: - * 1) it's unnecessary as interrupts remain disabled between - * syscore_suspend() and syscore_resume(): see create_image() and + * The stimer on CPU0 is not explicitly cleaned up here because: + * 1) it's harmless as interrupts remain disabled between + * syscore_suspend() and syscore_resume(), so the stimer cannot + * fire during this window: see create_image() and * resume_target_kernel() * 2) the stimer on CPU0 is automatically disabled later by * syscore_suspend() -> timekeeping_suspend() -> tick_suspend() -> ... * -> clockevents_shutdown() -> ... -> hv_ce_shutdown() - * 3) a warning would be triggered if we call - * clockevents_unbind_device(), which may sleep, in an - * interrupts-disabled context. */ hv_hyp_synic_disable_regs(0); From 7b74c117e2aac78e0f723e1c9c3644451c56b0d9 Mon Sep 17 00:00:00 2001 From: Michael Kelley Date: Tue, 1 Sep 2026 20:01:27 -0700 Subject: [PATCH 03/11] x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() hv_apicid_to_vp_index() currently uses the per-cpu hypercall input and output pages. This function is called when running in VTL2 and when running in an SEV-SNP CoCo VM with no paravisor. In the former case, the output page is allocated, but in the latter case it is not, so the hypervisor stores the output VP index in memory that has not been allocated by the guest. Fix this by using the input page for both input and output. The hypercall has very small input and output, so sharing the same page for both is straightforward. An alternative fix is to allocate the per-cpu output page when running in an SEV-SNP CoCo guest, but this uses significantly more memory, particularly with larger vCPUs counts. Fixes: 86c48271e0d6 ("x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap()") Signed-off-by: Michael Kelley Reviewed-by: Tianyu Lan Signed-off-by: Wei Liu --- arch/x86/hyperv/hv_init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 690f95295ee4..9900a5c59fd3 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -727,7 +727,8 @@ int hv_apicid_to_vp_index(u32 apic_id) input->partition_id = HV_PARTITION_ID_SELF; input->apic_ids[0] = apic_id; - output = *this_cpu_ptr(hyperv_pcpu_output_arg); + /* Treat input as having 2 APIC IDs so output is 64-bit aligned */ + output = (void *)input + struct_size(input, apic_ids, 2); control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_INDEX_FROM_APIC_ID; status = hv_do_hypercall(control, input, output); From ec31dc39e835ccde0930daccece8c492d28282fc Mon Sep 17 00:00:00 2001 From: Michael Kelley Date: Mon, 31 Aug 2026 20:45:14 -0700 Subject: [PATCH 04/11] Drivers: hv: Don't reset VMBus connection state on error/exit paths In two places, current code forces vmbus_connection.conn_state to DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect() calls vmbus_initiate_unload(), which unloads the VMBus connection only if the conn_state is CONNECTED. Consequently, the connection remains and the Hyper-V host might continue to send messages or post VMBus interrupts. The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback"), in that vmbus_initiate_unload() started checking the current connection state before doing the unload. This commit removed some occurrences where conn_state was forced to DISCONNECTED, but these two remained, apparently due to an oversight at the time. Fix this by not forcing conn_state to DISCONNECTED during VMBus exit, or if a failure occurs when establishing the connection in the first place. Whatever value conn_state has at the time is then read by vmbus_initiate_unload() to determine if there is a connection to be unloaded. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260805205806.B5AC31F000E9@smtp.kernel.org/ Fixes: 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback") Signed-off-by: Michael Kelley Signed-off-by: Wei Liu --- drivers/hv/connection.c | 1 - drivers/hv/vmbus_drv.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c index 1ab3581b096a..818667ef9c74 100644 --- a/drivers/hv/connection.c +++ b/drivers/hv/connection.c @@ -346,7 +346,6 @@ int vmbus_connect(void) cleanup: pr_err("Unable to connect to host\n"); - vmbus_connection.conn_state = DISCONNECTED; vmbus_disconnect(); kfree(msginfo); diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index c1edc3a5b673..4692687cdbf3 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -3039,7 +3039,6 @@ static void __exit vmbus_exit(void) hv_remove_kexec_handler(); hv_remove_crash_handler(); - vmbus_connection.conn_state = DISCONNECTED; hv_stimer_global_cleanup(); vmbus_disconnect(); if (vmbus_irq == -1) From 7724f2364396187163a73bdda43189b9e7c1aba9 Mon Sep 17 00:00:00 2001 From: Hemanth Selam Date: Tue, 15 Sep 2026 12:31:44 +0530 Subject: [PATCH 05/11] Drivers: hv: vmbus: fix typo "substract" in comment Correct "substract" to "subtract". Reviewed-by: Michael Kelley Signed-off-by: Hemanth Selam Signed-off-by: Wei Liu --- drivers/hv/channel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 7e4cc6f55237..a0883ddf32e2 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -79,7 +79,7 @@ static inline u32 hv_ring_gpadl_send_hvpgoffset(u32 offset) * therefore leaving a (PAGE_SIZE - HV_HYP_PAGE_SIZE) gap. * * And to calculate the effective send offset in gpadl, we need to - * substract this gap. + * subtract this gap. */ return (offset - (PAGE_SIZE - HV_HYP_PAGE_SIZE)) >> HV_HYP_PAGE_SHIFT; } From d5e689696017dfef8cd6f4eac895e6d23fa4a7bb Mon Sep 17 00:00:00 2001 From: Hemanth Selam Date: Tue, 15 Sep 2026 12:31:45 +0530 Subject: [PATCH 06/11] tools/hv: fix typo "retrive" in comment Correct "retrive" to "retrieve". Reviewed-by: Michael Kelley Signed-off-by: Hemanth Selam Signed-off-by: Wei Liu --- tools/hv/hv_get_dns_info.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hv/hv_get_dns_info.sh b/tools/hv/hv_get_dns_info.sh index 268521234d4b..288821565eee 100755 --- a/tools/hv/hv_get_dns_info.sh +++ b/tools/hv/hv_get_dns_info.sh @@ -1,6 +1,6 @@ #!/bin/sh -# This example script parses /etc/resolv.conf to retrive DNS information. +# This example script parses /etc/resolv.conf to retrieve DNS information. # In the interest of keeping the KVP daemon code free of distro specific # information; the kvp daemon code invokes this external script to gather # DNS information. From 874194a8de75fc2f4d1fb70c670b289b7e48f93e Mon Sep 17 00:00:00 2001 From: Hardik Garg Date: Fri, 11 Sep 2026 17:51:46 +0000 Subject: [PATCH 07/11] mshv_vtl: Check per-CPU register page before mmap Register-page setup is optional for each CPU. If allocation or registration fails, mshv_vtl_configure_reg_page() warns and leaves that CPU's reg_page NULL, but initial context setup continues successfully. Meanwhile, successful setup on another CPU sets the global mshv_has_reg_page flag. mshv_vtl_fault() checks this global flag before selecting the requested CPU's register page. With mixed setup results across online CPUs, the check passes even for a CPU with no register page, reaching get_page(NULL) when userspace faults in that mapping. Check the selected per-CPU register page before taking its reference and return VM_FAULT_SIGBUS if it is absent. Fixes: 7bfe3b8ea6e3 ("Drivers: hv: Introduce mshv_vtl driver") Cc: stable@vger.kernel.org Signed-off-by: Hardik Garg Reviewed-by: Naman Jain Signed-off-by: Wei Liu --- drivers/hv/mshv_vtl_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c index 6e3c11c68171..d8225242c73f 100644 --- a/drivers/hv/mshv_vtl_main.c +++ b/drivers/hv/mshv_vtl_main.c @@ -819,6 +819,9 @@ static vm_fault_t mshv_vtl_fault(struct vm_fault *vmf) return VM_FAULT_NOPAGE; } + if (!page) + return VM_FAULT_SIGBUS; + get_page(page); vmf->page = page; From 12f631d5ded523b56cbd3db350b0a768a4d13d1a Mon Sep 17 00:00:00 2001 From: Long Li Date: Mon, 14 Sep 2026 21:31:50 -0700 Subject: [PATCH 08/11] MAINTAINERS: remove myself from the Hyper-V entries I am no longer maintaining the Hyper-V/Azure core and drivers, or the Hyper-V synthetic video DRM driver. Signed-off-by: Long Li Signed-off-by: Wei Liu --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6215fcb07770..baabd1299e8b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8168,7 +8168,6 @@ F: drivers/gpu/drm/tiny/hx8357d.c DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE M: Dexuan Cui -M: Long Li M: Saurabh Sengar L: linux-hyperv@vger.kernel.org L: dri-devel@lists.freedesktop.org @@ -12162,7 +12161,6 @@ M: "K. Y. Srinivasan" M: Haiyang Zhang M: Wei Liu M: Dexuan Cui -M: Long Li L: linux-hyperv@vger.kernel.org S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git From c37fc4deee0065e444306def9c79ba22b9b0f84e Mon Sep 17 00:00:00 2001 From: Naman Jain Date: Mon, 7 Sep 2026 05:47:42 +0000 Subject: [PATCH 09/11] PCI: hv: Probe vPCI buses asynchronously On Hyper-V guests each virtual PCI bus is enumerated by its own hv_pci_probe() call. The probe performs several synchronous host request/response exchanges while negotiating the protocol, querying bus relations, entering D0, and reporting allocated resources. These waits are latency-bound rather than CPU-bound. hv_pci registers as an ordinary VMBus driver, so driver_register() walks matching vPCI buses and probes them sequentially while the driver's initcall runs. On guests that expose several devices, each through its own vPCI bus, this serialization adds the host round-trip latencies to device initialization. Each bus is described by its own struct hv_pcibus_device, so independent buses can be probed concurrently. Request asynchronous probing via PROBE_PREFER_ASYNCHRONOUS, causing the driver core to schedule matching buses for asynchronous probe work. On an Azure Standard_L32s_v3 guest with five vPCI targets (four NVMe controllers and one Mellanox VF), Linux 7.2.3 was tested with one warm-up and three measured boots per variant. The median interval from the first hv_pci_probe() entry to the last return decreased from 2847.968 ms to 2786.709 ms, a 61.259 ms (2.15%) improvement. Co-developed-by: Dexuan Cui Signed-off-by: Dexuan Cui Signed-off-by: Naman Jain Reviewed-by: Sahil Chandna Signed-off-by: Wei Liu --- drivers/pci/controller/pci-hyperv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 89816a2bd7cd..056d379b3cee 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -4155,6 +4155,9 @@ static struct hv_driver hv_pci_drv = { .remove = hv_pci_remove, .suspend = hv_pci_suspend, .resume = hv_pci_resume, + .driver = { + .probe_type = PROBE_PREFER_ASYNCHRONOUS, + }, }; static void __exit exit_hv_pci_drv(void) From ca039df94983c441fdee0e2488263fc744e8ecb6 Mon Sep 17 00:00:00 2001 From: Sahil Chandna Date: Mon, 14 Sep 2026 03:39:09 -0700 Subject: [PATCH 10/11] PCI: hv: Warn when wait_for_response() waits indefinitely A guest can wait indefinitely in wait_for_response() for the host to send either a rescind message or a packet completion. If the host does not send either, the guest can remain blocked with no diagnostic indicating a reason. This was observed during a guest kernel upgrade in which the host-side application handling the PCI channel faulted, causing the guest to never receive the completion request. Add a warning in wait_for_response() when the wait exceeds a timeout so that such a hang is visible in the guest's kernel log and can be correlated with host-side state. Suggested-by: Michael Kelley Reviewed-by: Naman Jain Signed-off-by: Sahil Chandna Signed-off-by: Wei Liu --- drivers/pci/controller/pci-hyperv.c | 46 ++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 056d379b3cee..85d826f8f68d 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -1040,19 +1040,38 @@ static void put_pcichild(struct hv_pci_dev *hpdev) /* * There is no good way to get notified from vmbus_onoffer_rescind(), - * so let's use polling here, since this is not a hot path. + * so let's use polling here, since this is not a hot path. If + * wait_for_response() has been polling for 2 minutes + * without either a rescind or completion, add a warning. */ +#define PCI_RESPONSE_WARN_POLL_COUNT 1200 + static int wait_for_response(struct hv_device *hdev, - struct completion *comp) + struct completion *comp, + const char *msg_type) { + u64 counter = 0; + while (true) { if (hdev->channel->rescind) { dev_warn_once(&hdev->device, "The device is gone.\n"); return -ENODEV; } - if (wait_for_completion_timeout(comp, HZ / 10)) + counter++; + + if (wait_for_completion_timeout(comp, HZ / 10)) { + if (counter > PCI_RESPONSE_WARN_POLL_COUNT) + dev_warn(&hdev->device, + "Late %s completion arrived.\n", msg_type); break; + } + + if (counter == PCI_RESPONSE_WARN_POLL_COUNT) { + dev_err(&hdev->device, + "%s stuck waiting for response, relid = %u\n", + msg_type, hdev->channel->offermsg.child_relid); + } } return 0; @@ -1518,7 +1537,8 @@ static int hv_read_config_block(struct pci_dev *pdev, void *buf, if (ret) return ret; - ret = wait_for_response(hbus->hdev, &comp_pkt.comp_pkt.host_event); + ret = wait_for_response(hbus->hdev, &comp_pkt.comp_pkt.host_event, + "PCI_READ_BLOCK"); if (ret) return ret; @@ -1607,7 +1627,8 @@ static int hv_write_config_block(struct pci_dev *pdev, void *buf, if (ret) return ret; - ret = wait_for_response(hbus->hdev, &comp_pkt.host_event); + ret = wait_for_response(hbus->hdev, &comp_pkt.host_event, + "PCI_WRITE_BLOCK"); if (ret) return ret; @@ -2624,7 +2645,8 @@ static struct hv_pci_dev *new_pcichild_device(struct hv_pcibus_device *hbus, if (ret) goto error; - if (wait_for_response(hbus->hdev, &comp_pkt.host_event)) + if (wait_for_response(hbus->hdev, &comp_pkt.host_event, + "PCI_QUERY_RESOURCE_REQUIREMENTS")) goto error; hpdev->desc = *desc; @@ -3256,7 +3278,8 @@ static int hv_pci_protocol_negotiation(struct hv_device *hdev, (unsigned long)pkt, VM_PKT_DATA_INBAND, VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED); if (!ret) - ret = wait_for_response(hdev, &comp_pkt.host_event); + ret = wait_for_response(hdev, &comp_pkt.host_event, + "PCI_QUERY_PROTOCOL_VERSION"); if (ret) { dev_err(&hdev->device, @@ -3476,7 +3499,8 @@ enter_d0_retry: (unsigned long)pkt, VM_PKT_DATA_INBAND, VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED); if (!ret) - ret = wait_for_response(hdev, &comp_pkt.host_event); + ret = wait_for_response(hdev, &comp_pkt.host_event, + "PCI_BUS_D0ENTRY"); if (ret) goto exit; @@ -3553,7 +3577,8 @@ static int hv_pci_query_relations(struct hv_device *hdev) ret = vmbus_sendpacket(hdev->channel, &message, sizeof(message), 0, VM_PKT_DATA_INBAND, 0); if (!ret) - ret = wait_for_response(hdev, &comp); + ret = wait_for_response(hdev, &comp, + "PCI_QUERY_BUS_RELATIONS"); /* * In the case of fast device addition/removal, it's possible that @@ -3644,7 +3669,8 @@ static int hv_send_resources_allocated(struct hv_device *hdev) VM_PKT_DATA_INBAND, VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED); if (!ret) - ret = wait_for_response(hdev, &comp_pkt.host_event); + ret = wait_for_response(hdev, &comp_pkt.host_event, + "PCI_RESOURCE_ASSIGNED"); if (ret) break; From dbc393f6f009a2bf7e4a22ef2d70b53f533f20f4 Mon Sep 17 00:00:00 2001 From: Wei Liu Date: Thu, 15 Oct 2026 00:48:50 -0700 Subject: [PATCH 11/11] MAINTAINERS: drop KY from Hyper-V maintainers list KY has retired from Microsoft. Signed-off-by: Wei Liu --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index baabd1299e8b..b3ee404564e8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12157,7 +12157,6 @@ S: Maintained F: drivers/media/i2c/hi847.c Hyper-V/Azure CORE AND DRIVERS -M: "K. Y. Srinivasan" M: Haiyang Zhang M: Wei Liu M: Dexuan Cui