[libvirt] [PATCH] remove redundant condition
by Ján Tomko
If the address type is SPAPRVIO, it will match the != NONE condition.
---
src/qemu/qemu_command.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3886b4f..078ecf7 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -2423,8 +2423,6 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
def->controllers[i]->idx == 0)
continue;
- if (def->controllers[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO)
- continue;
if (def->controllers[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
continue;
--
2.3.6
10 years
[libvirt] [PATCH] tests: Sort EXTRA_DIST in the Makefile
by Michal Privoznik
We tend to keep the folders in the EXTRA_DIST sorted alphabetically.
However, we've failed sometimes and the list is not ordered anymore.
Reorder it back.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tests/Makefile.am | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a1cca5c..8e3ab91 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -72,6 +72,7 @@ LDADDS = \
../src/libvirt.la
EXTRA_DIST = \
+ .valgrind.supp \
bhyvexml2argvdata \
bhyvexml2xmloutdata \
capabilityschemadata \
@@ -93,12 +94,12 @@ EXTRA_DIST = \
lxcxml2xmldata \
lxcxml2xmloutdata \
networkschematest \
+ networkxml2confdata \
+ networkxml2firewalldata \
networkxml2xmlin \
networkxml2xmlout \
- networkxml2confdata \
networkxml2xmlupdatein \
networkxml2xmlupdateout \
- networkxml2firewalldata \
nodedevschemadata \
nodedevschematest \
nodeinfodata \
@@ -116,41 +117,40 @@ EXTRA_DIST = \
qemuxml2argvdata \
qemuxml2xmloutdata \
qemuxmlnsdata \
+ schematestutils.sh \
secretxml2xmlin \
securityselinuxhelperdata \
securityselinuxlabeldata \
- schematestutils.sh \
sexpr2xmldata \
storagepoolschemadata \
storagepoolschematest \
storagepoolxml2xmlin \
storagepoolxml2xmlout \
- storagevolxml2argvdata \
storagevolschemadata \
storagevolschematest \
+ storagevolxml2argvdata \
storagevolxml2xmlin \
storagevolxml2xmlout \
sysinfodata \
test-lib.sh \
- vircaps2xmldata \
vboxsnapshotxmldata \
- virsh-uriprecedence \
+ vircaps2xmldata \
vircgroupdata \
virfiledata \
+ virmock.h
virnetdaemondata \
virnetdevtestdata \
virpcitestdata \
virscsidata \
+ virsh-uriprecedence \
virusbtestdata \
+ vmwareverdata \
vmx2xmldata \
xencapsdata \
- xmconfigdata \
xlconfigdata \
+ xmconfigdata \
xml2sexprdata \
xml2vmxdata \
- vmwareverdata \
- .valgrind.supp \
- virmock.h
test_helpers = commandhelper ssh test_conf
test_programs = virshtest sockettest \
--
2.3.6
10 years
[libvirt] [PATCH] daemon: Don't just include admin RPC
by Michal Privoznik
So, it's a little paradox that we use the file twice. Firstly to build
libvirt-admin.la (a client side of the Admin API), then once again to
build the server side. Well, the problem is, this does not play nicely
with the distclean since the file is generated. So while it's removed
in the src/ the distclean running in daemon/ will not find the file
and fail. The file is needed because it contains the RPC wrappers. So
let's leave the client code as is and from the daemon/ just link the
client library. The linker will find desired symbols and use them.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
daemon/Makefile.am | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index b9c089d..d3fc029 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -128,8 +128,7 @@ libvirtd_conf_la_LIBADD = $(LIBXML_LIBS)
noinst_LTLIBRARIES += libvirtd_admin.la
libvirtd_admin_la_SOURCES = \
- admin_server.c admin_server.h \
- ../src/admin/admin_protocol.c
+ admin_server.c admin_server.h
libvirtd_admin_la_CFLAGS = \
$(AM_CFLAGS) \
@@ -145,6 +144,9 @@ libvirtd_admin_la_LDFLAGS = \
$(COVERAGE_LDFLAGS) \
$(NO_INDIRECT_LDFLAGS)
+libvirtd_admin_la_LIBADD = \
+ ../src/libvirt-admin.la
+
man8_MANS = libvirtd.8
sbin_PROGRAMS = libvirtd
--
2.3.6
10 years
[libvirt] nodedev-dumpxml doesn't refresh supported offload NIC capabilities
by Moshe Levi
Hi,
I was playing with the nodedev-dumpxml to see the supported offload NIC capabilities, and
It seem that if I disable one of offloading capabilities using ethtool command nodedev-dumpxml it still return
the feature as enabled. To get the correct offloading capabilities I have to restart libvirtd.
I was wandering if that is an expected behavior in lbivirt .
Please see example below with the rx capabilities disabled.
virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81
<device>
<name>net_enp4s0_f4_52_14_11_73_81</name>
<path>/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/net/enp4s0</path>
<parent>pci_0000_04_00_0</parent>
<capability type='net'>
<interface>enp4s0</interface>
<address>f4:52:14:11:73:81</address>
<link speed='40000' state='up'/>
<feature name='rx'/>
<feature name='tx'/>
<feature name='sg'/>
<feature name='tso'/>
<feature name='gso'/>
<feature name='gro'/>
<feature name='rxvlan'/>
<feature name='txvlan'/>
<feature name='rxhash'/>
<capability type='80203'/>
</capability>
</device>
ethtool -K enp4s0 rx off
virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81
<device>
<name>net_enp4s0_f4_52_14_11_73_81</name>
<path>/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/net/enp4s0</path>
<parent>pci_0000_04_00_0</parent>
<capability type='net'>
<interface>enp4s0</interface>
<address>f4:52:14:11:73:81</address>
<link speed='40000' state='up'/>
<feature name='rx'/>
<feature name='tx'/>
<feature name='sg'/>
<feature name='tso'/>
<feature name='gso'/>
<feature name='gro'/>
<feature name='rxvlan'/>
<feature name='txvlan'/>
<feature name='rxhash'/>
<capability type='80203'/>
</capability>
</device>
virsh #
[root@r-ae-host05 bin]# ps -ef | grep libvirt
root 16743 23086 0 16:43 pts/2 00:00:00 ../sbin/libvirtd
root 17440 23086 0 16:47 pts/2 00:00:00 grep --color=auto libvirt
[root@r-ae-host05 bin]# kill 16743
[root@r-ae-host05 bin]# ../sbin/libvirtd &
[2] 17489
[1] Done ../sbin/libvirtd
[root@r-ae-host05 bin]#
[root@r-ae-host05 bin]#
[root@r-ae-host05 bin]# ./virsh
virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81
<device>
<name>net_enp4s0_f4_52_14_11_73_81</name>
<path>/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/net/enp4s0</path>
<parent>pci_0000_04_00_0</parent>
<capability type='net'>
<interface>enp4s0</interface>
<address>f4:52:14:11:73:81</address>
<link speed='40000' state='up'/>
<feature name='tx'/>
<feature name='sg'/>
<feature name='tso'/>
<feature name='gso'/>
<feature name='gro'/>
<feature name='rxvlan'/>
<feature name='txvlan'/>
<feature name='rxhash'/>
<feature name='rdma'/>
<capability type='80203'/>
</capability>
</device>
Thanks,
Moshe Levi.
10 years
[libvirt] [PATCH] nodedev: update netdev feature bits before each dumpxml
by Laine Stump
As with several other attributes of devices (link status, sriov VF
list, IOMMU group list), the detdev feature bits aren't automatically
updated in the nodedev driver's cache when they change. In order to
get a properly up-to-date list when getting the XML of a device, we
must reget them in update-caps prior to each dumpxml.
Reported-By: Moshe Levi <moshele(a)mellanox.com>
---
I dislike needing to put in the virBitmapFree and set the pointer to
NULL before re-getting the features, but leaving it out would lead to
a leak of the old bitmap, and I'm not sure I want
virNetDevGetFeatures() to assume a valid pointer when it starts (it
currently assumes the pointer contents is junk, and overwrites it with
a newly allocated *virBitmap).
src/node_device/node_device_driver.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c
index 768db7f..31741b9 100644
--- a/src/node_device/node_device_driver.c
+++ b/src/node_device/node_device_driver.c
@@ -58,6 +58,10 @@ static int update_caps(virNodeDeviceObjPtr dev)
case VIR_NODE_DEV_CAP_NET:
if (virNetDevGetLinkInfo(cap->data.net.ifname, &cap->data.net.lnk) < 0)
return -1;
+ virBitmapFree(cap->data.net.features);
+ cap->data.net.features = NULL;
+ if (virNetDevGetFeatures(cap->data.net.ifname, &cap->data.net.features) < 0)
+ return -1;
break;
case VIR_NODE_DEV_CAP_PCI_DEV:
if (nodeDeviceSysfsGetPCIRelatedDevCaps(dev->def->sysfs_path,
--
2.1.0
10 years
[libvirt] VIRTIO v1.0 15-day public review - ends July 2nd
by Chet Ensign
OASIS members and other interested parties,
The Virtual I/O Device (VIRTIO) TC members [1] have produced an updated
Committee Specification Draft (CSD) and submitted this specification for
15-day public review:
Virtual I/O Device (VIRTIO) Version 1.0
Committee Specification Draft 04 / Public Review Draft 04
28 May 2015
Specification overview:
This document describes the specifications of the "virtio" family of
devices. These devices are found in virtual environments, yet by design
they are not all that different from physical devices, and this document
treats them as such. This allows the guest to use standard drivers and
discovery mechanisms.
The purpose of virtio and this specification is that virtual environments
and guests should have a straightforward, efficient, standard and
extensible mechanism for virtual devices, rather than boutique
per-environment or per-OS mechanisms.
Among multiple other enhancements and corrections, the Virtio specification
now includes support for the memory balloon device for managing guest
memory. This puts Virtio 1.0 at feature parity with Virtio 0.9.
This is the first public review of VIRTIO since it was approved as
Committee Specification 02 (CS02). The files
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
and
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
include all changes since CS02 highlighted.
TC Description:
The goal of the OASIS Virtual I/O Device (VIRTIO) TC is to simplify virtual
devices, making them more extensible and more recognizable.
The purpose of VIRTIO is to ensure that virtual environments and guests
have a straightforward, efficient, standard, and extensible mechanism for
virtual devices, rather than boutique per-environment or per-OS mechanisms.
Public Review Period:
The public review starts 18 June 2015 at 00:00 UTC and ends 02 July 2015 at
23:59 UTC.
This is the first public review of VIRTIO since it was approved as
Committee Specification 02 (CS02). The files
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
and
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
include all changes since CS02 highlighted [2]. This 15-day review is
limited in scope to these changes.
This is an open invitation to comment. OASIS solicits feedback from
potential users, developers and others, whether OASIS members or not, for
the sake of improving the interoperability and quality of its technical
work.
Reviewers may provide comments directly from the comment-tag version of
document. The file
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
contains the HTML version of the draft with a “[comment?]” link next to
each section heading. Clicking on this link will launch your email
application and begin a message to virtio-comment(a)lists.oasis-open.org with
the specific section number and title in the subject line. Simply enter
your comment and click send.
Note that you must be subscribed to the comment mailing list before sending
feedback. Instructions on how to subscribe can be found at
https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio.
URIs:
The prose specification document and related files are available here:
Editable source (Authoritative):
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/tex/
HTML:
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
HTML with inline tags for direct commenting:
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
PDF:
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
ZIP distribution files (complete):
For your convenience, OASIS provides a complete package of the prose
specification and related files in a ZIP distribution file. You can
download the ZIP file here:
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
Additional information about this specification and the VIRTIO TC may be
found on the TC's public home page located at:
http://www.oasis-open.org/committees/virtio/
Comments may be submitted to the TC by any person through the use of the
OASIS TC Comment Facility which can be accessed via the button labeled
"Send A Comment" at the top of the TC public home page, or directly at:
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=virtio
Feedback submitted by TC non-members for this work and for other work of
this TC is publicly archived and can be viewed at:
http://lists.oasis-open.org/archives/virtio-comment/
All comments submitted to OASIS are subject to the OASIS Feedback License,
which ensures that the feedback you provide carries the same obligations at
least as the obligations of the TC members. In connection with this public
review of 'Virtual I/O Device (VIRTIO) Version 1.0', we call your attention
to the OASIS IPR Policy [3] applicable especially [4] to the work of this
technical committee. All members of the TC should be familiar with this
document, which may create obligations regarding the disclosure and
availability of a member's patent, copyright, trademark and license rights
that read on an approved OASIS specification. OASIS invites any persons who
know of any such claims to disclose these if they may be essential to the
implementation of the above specification, so that notice of them may be
posted to the notice page for this TC's work.
========== Additional references:
[1] Virtual I/O Device (VIRTIO) TC
http://www.oasis-open.org/committees/virtio/
[2] Redlined DIFF file:
http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04...
[3] http://www.oasis-open.org/policies-guidelines/ipr
[4] http://www.oasis-open.org/committees/virtio/ipr.php
https://www.oasis-open.org/policies-guidelines/ipr#licensing_req
Non-Assertion Mode
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
10 years
[libvirt] [PATCH 0/3] parallels: add statistiscs
by Nikolay Shirokovskiy
Add vz statistics for network, cpu and memory.
src/vz/vz_driver.c | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++-
src/vz/vz_sdk.c | 69 ++++++++++++++++++++++++++-
src/vz/vz_sdk.h | 4 ++
10 years
[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
by Pavel Fedin
Hello ?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -----Original Message-----
> From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf
Of
> Pavel Fedin
> Sent: Thursday, June 11, 2015 9:41 AM
> To: libvir-list(a)redhat.com
> Cc: Pavel Fedin
> Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
>
> Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use
> PCI devices. This provides performance improvement as well as vhost-net with
> irqfd support for virtio-net. However libvirt still insists on virtio devices
> attached to virt machine to have MMIO bindings. This patch allows to use both.
> If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by
> default.
>
> Changes since v1:
> - Added capability based on qemu version number
> - Recognize also "virt-" prefix
>
> Pavel Fedin (2):
> Introduce QEMU_CAPS_ARM_VIRT_PCI
> Allow PCI virtio on ARM "virt" machine
>
> src/qemu/qemu_capabilities.c | 5 +++++
> src/qemu/qemu_capabilities.h | 1 +
> src/qemu/qemu_command.c | 15 ++++++++++++---
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> --
> 1.9.5.msysgit.0
>
> --
> libvir-list mailing list
> libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
10 years
[libvirt] [PATCH 0/3] Fix yet again some Admin API bugs
by Michal Privoznik
Pushed under trivial and build-breaker rules. The 'make rpm' is broken.
There is still one issue I'm chasing down. Running 'distcheck' shows some errors.
Michal Privoznik (3):
daemon: Distribute admin_server.h
tests: Follow virnetserver to virnetdaemon transition
libvirt.spec: Don't expect virt-admin in libvirt-admin yet
daemon/Makefile.am | 2 +-
libvirt.spec.in | 2 --
tests/Makefile.am | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
--
2.3.6
10 years
[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
by Pavel Fedin
Knock-knock???
Sorry for possibly repeated PING, but i see that mailing list for some reason strips
CC:'s if specified without real name, so retry with name this time.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -----Original Message-----
> From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf
Of
> Pavel Fedin
> Sent: Thursday, June 11, 2015 9:41 AM
> To: libvir-list(a)redhat.com
> Cc: Pavel Fedin
> Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
>
> Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use
> PCI devices. This provides performance improvement as well as vhost-net with
> irqfd support for virtio-net. However libvirt still insists on virtio devices
> attached to virt machine to have MMIO bindings. This patch allows to use both.
> If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by
> default.
>
> Changes since v1:
> - Added capability based on qemu version number
> - Recognize also "virt-" prefix
>
> Pavel Fedin (2):
> Introduce QEMU_CAPS_ARM_VIRT_PCI
> Allow PCI virtio on ARM "virt" machine
>
> src/qemu/qemu_capabilities.c | 5 +++++
> src/qemu/qemu_capabilities.h | 1 +
> src/qemu/qemu_command.c | 15 ++++++++++++---
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> --
> 1.9.5.msysgit.0
>
> --
> libvir-list mailing list
> libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
10 years
