Fails to start inside PV domU

Description of problem:
Xen PV domU's have no PCI bus (at least as seen on Rackspace's Cloud Servers). libvirt's src/node_device/node_device_udev.c calls pci_system_init which looks for /sys/bus/pci. If it does not find /sys/bus/pci (which it won't in a Xen PV domU) it returns unsuccesfully, which libvirt considers fatal.

It's perfectly reasonable to want to run libvirt in a paravirt Xen domU, e.g. for running LXC, QEmu or UML guests. Additionally, the PCI check is disabled on s390, and a failing check is ignored for qemu:///session, so I don't see how it can be absolutely required for qemu:///system on non-s390.

Version-Release number of selected component (if applicable):
Observed in 0.8.8 and onwards. Perhaps it appeared earlier.

How reproducible:
100%

Steps to Reproduce:
1. Fire up a Xen PV domU (e.g. on Rackspace Cloud Servers)
2. Attempt to start libvirtd as root.
3. Fail.

Actual results:
It fails, saying something like:
libpciaccess: No such file or directory.

Expected results:
It should start, and whatever functionality depends on pci access should simply be disabled. Since s390 gets away with this, it should be feasible.

Additional info:

Fix is now upstream, and will be part of libvirt 0.9.5:

commit 9c7283166f667967d9d435ba233178f07af2eee0
Author: Soren Hansen <email address hidden>
Date: Mon Sep 5 21:29:06 2011 +0200

    Don't treat pci_system_init failure as fatal if no PCI bus is present

    Xen PV domU's have no PCI bus. node_device_udev.c calls pci_system_init
    won't in a Xen PV domU) it returns unsuccesfully (ENOENT), which libvirt
    considers fatal. This makes libvirt unusable in this environment, even
    though there are plenty of valid virtualisation options that work
    there (LXC, UML, and QEmu spring to mind)