this commit addresses the same issue that as commit 1af45804 does.

the following message is copying from that commit:
   If we find ourselves in the situation that the 'add' uevent has been
   fired earlier than the sysfs tree for a device was created, we should
   use the best-effort approach and give kernel some predetermined amount
   of time, thus waiting for the attributes to be ready rather than
   discarding the device from our device list forever. If those don't appear
   in the given time frame, we need to move on, since libvirt can't wait
   indefinitely.

Signed-off-by: Guoyi Tu <tugy@chinatelecom.cn>
---
  src/node_device/node_device_udev.c | 9 +++++++++
  1 file changed, 9 insertions(+)

diff --git a/src/node_device/node_device_udev.c 
b/src/node_device/node_device_udev.c
index 1d8486f623..4a1786c21c 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -427,10 +427,19 @@ udevProcessPCI(virNodeDeviceDriverState *driver_state,
      virPCIEDeviceInfo *pci_express = NULL;
      virPCIDevice *pciDev = NULL;
      virPCIDeviceAddress devAddr = { 0 };
+    g_autofree char *linkpath = NULL;
      int ret = -1;
      char *p;
      bool privileged = false;

+    linkpath = g_strdup_printf("%s/config", 
udev_device_get_syspath(device));
+    if (virFileWaitForExists(linkpath, 10, 100) < 0) {
+        virReportSystemError(errno,
+                             _("failed to wait for file '%1$s' to appear"),
+                             linkpath);
+        goto cleanup;
+    }
+
      VIR_WITH_MUTEX_LOCK_GUARD(&driver_state->lock) {
          privileged = driver_state->privileged;
      }
-- 
2.27.0


--
Guoyi