[libvirt] [PATCH] Fix disability to run on systems with no PCI bus
The patch which moved libpciaccess initialization to one place caused regression - we were not able to run on system with no PCI bus, like s390(x). This patch fix it. --- src/node_device/node_device_udev.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 2139ef3..b6335ff 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1603,7 +1603,13 @@ static int udevDeviceMonitorStartup(int privileged) char ebuf[256]; VIR_ERROR(_("Failed to initialize libpciaccess: %s"), virStrerror(pciret, ebuf, sizeof ebuf)); +#if defined __s390__ || defined __s390x_ + /* On x390(x) system there is no PCI bus. + * Therefore we do not want to return error here */ + ret = 0; +#else ret = -1; +#endif goto out; } } -- 1.7.4.4
On Fri, Apr 22, 2011 at 09:58:38 +0200, Michal Privoznik wrote:
The patch which moved libpciaccess initialization to one place caused regression - we were not able to run on system with no PCI bus, like s390(x). This patch fix it. --- src/node_device/node_device_udev.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 2139ef3..b6335ff 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1603,7 +1603,13 @@ static int udevDeviceMonitorStartup(int privileged) char ebuf[256]; VIR_ERROR(_("Failed to initialize libpciaccess: %s"), virStrerror(pciret, ebuf, sizeof ebuf)); +#if defined __s390__ || defined __s390x_ + /* On x390(x) system there is no PCI bus. + * Therefore we do not want to return error here */ + ret = 0; +#else ret = -1; +#endif goto out; } }
Why do we try to initialize libpciaccess if we know it won't succeed? What about just completely dropping libpciaccess dependency on s390(x)? Jirka
On 04/22/2011 10:19 AM, Jiri Denemark wrote:
On Fri, Apr 22, 2011 at 09:58:38 +0200, Michal Privoznik wrote:
The patch which moved libpciaccess initialization to one place caused regression - we were not able to run on system with no PCI bus, like s390(x). This patch fix it. --- src/node_device/node_device_udev.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 2139ef3..b6335ff 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1603,7 +1603,13 @@ static int udevDeviceMonitorStartup(int privileged) char ebuf[256]; VIR_ERROR(_("Failed to initialize libpciaccess: %s"), virStrerror(pciret, ebuf, sizeof ebuf)); +#if defined __s390__ || defined __s390x_ + /* On x390(x) system there is no PCI bus. + * Therefore we do not want to return error here */ + ret = 0; +#else ret = -1; +#endif goto out; } }
Why do we try to initialize libpciaccess if we know it won't succeed? What about just completely dropping libpciaccess dependency on s390(x)?
Jirka
Well, although investigation on the internet shows there is at least PCI-like bus, linux kernel doesn't know how to use it (see arch/s390/include/asm/pci.h) which is the most important. so NAK and prepare v2. Michal
Hello there, I wrote in February this year following: boromir:/ # qemu-system-s390x --enable-kvm -monitor stdio VNC server running on `::1:5900' QEMU 0.12.50 monitor - type 'help' for more information (qemu) info qtree bus: main-system-bus type System dev: s390-virtio-bridge, id "" bus: s390-virtio type s390-virtio dev: virtio-serial-s390, id "" dev-prop: max_ports = 31 bus: virtio-serial-bus.0 type virtio-serial-bus dev: virtconsole, id "" dev-prop: is_console = 1 dev-prop: chardev = virtcon0 dev-prop: name = <null> dev-prop-int: id: 0 dev-prop-int: guest_connected: 1 dev-prop-int: host_connected: 1 dev: virtio-net-s390, id "" dev-prop: mac = 52:54:00:12:34:56 dev-prop: vlan = 0 dev-prop: netdev = <null> (qemu) quit You can see that on s390 there is a Bus called 's390-virtio'. This works also on our s390x (z9) Machine. Regards Patrick Siegl Am 22.04.2011 11:00, schrieb Michal Prívozník:
On 04/22/2011 10:19 AM, Jiri Denemark wrote:
On Fri, Apr 22, 2011 at 09:58:38 +0200, Michal Privoznik wrote:
The patch which moved libpciaccess initialization to one place caused regression - we were not able to run on system with no PCI bus, like s390(x). This patch fix it. --- src/node_device/node_device_udev.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 2139ef3..b6335ff 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1603,7 +1603,13 @@ static int udevDeviceMonitorStartup(int privileged) char ebuf[256]; VIR_ERROR(_("Failed to initialize libpciaccess: %s"), virStrerror(pciret, ebuf, sizeof ebuf)); +#if defined __s390__ || defined __s390x_ + /* On x390(x) system there is no PCI bus. + * Therefore we do not want to return error here */ + ret = 0; +#else ret = -1; +#endif goto out; } }
Why do we try to initialize libpciaccess if we know it won't succeed? What about just completely dropping libpciaccess dependency on s390(x)?
Jirka
Well, although investigation on the internet shows there is at least PCI-like bus, linux kernel doesn't know how to use it (see arch/s390/include/asm/pci.h) which is the most important. so NAK and prepare v2.
Michal
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Jiri Denemark -
Michal Privoznik -
Michal Prívozník
-
Patrick Siegl