Re: [PATCH] PCI: hv: Probe vPCI buses asynchronously
From: Naman Jain
Date: Tue Sep 22 2026 - 05:14:55 EST
On 9/22/2026 2:39 AM, Michael Kelley wrote:
From: Naman Jain <namjain@xxxxxxxxxxxxxxxxxxx> Sent: Sunday, September 6, 2026 10:48 PM
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.
The elapsed time improvement is rather disappointing given the
complexity of the probing sequence and the number of interactions
with the Hyper-V host. Do you have any insight into why there isn't a
larger reduction? Is something mostly serializing the work even though
PROBE_PREFER_ASYNCHRONOUS is specified?
Michael
I can see these reasons for not seeing great improvements:
1. Timing of device offers from the host is beyond the control of guest and the Hyper-V host may also be serializing the requests from the host.
2. Shared locks that needs to be handled separately:
* hyperv_mmio_lock during VMBus MMIO allocation.
* pci_rescan_remove_lock during PCI resource assignment and device addition.
I digged more into it, and it is indeed because of late offers from Hyper-V. I was considering the start of first probe to the last return, for time calculations.
For the 4 PCI devices on my setup whose offers were delivered together, the performance improvement was about 24%. However with the last offer coming late for MLX PCI device, overall improvement in time was lesser in terms of percentage.
Dexuan had removed pci_rescan_remove_lock in his previous upstream attempt, but I ommitted it intentionally this time because from AI review, I saw a potential race condition that we would introduce if we remove it. Secondly, I did not observe any benefits of removing this lock. But I am going to revisit it again.
Regards,
Naman
Co-developed-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
Signed-off-by: Naman Jain <namjain@xxxxxxxxxxxxxxxxxxx>
---
Previous discussion around this change:
https://lore.kernel.org/all/20230420024037.5921-7-decui@xxxxxxxxxxxxx/
Skipping removal of pci_rescan_remove_lock, due to possible
synchronization problems associated with this lock removal. Also, with
my current setup, I was not able to see much improvements with this
change, so keeping it for later. Asynchronous probing change is not
dependent on this.
---
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 89816a2bd7cd3..056d379b3cee4 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)
--
2.43.0