date:20170329

Re: [libvirt] [PATCH v4 00/14] Introduce vGPU mdev framework to libvirt

2017-03-29 Thread yonglihe


On 03/28/2017 10:05 PM, yonglihe wrote:

On 2017年03月27日 15:42, yonglihe wrote:

Verify Summary:
* the none rooted mode starting a high-privileges VM actually.

The configurations is source generated default value except tls disabled.


1. rooted

virsh define ./libvirt/vgpu-win10.xml
Domain vgpu-win10 defined from ./libvirt/vgpu-win10.xml

ubuntu@z-nuc-11:~/vgpu-meta/libvirt-stage$ virsh start vgpu-win10
2017-03-26 23:28:57.385+: 2886: info : libvirt version: 3.2.0
2017-03-26 23:28:57.385+: 2886: info : hostname: z-nuc-11.maas
2017-03-26 23:28:57.385+: 2886: warning : qemuDomainObjTaint:4155
: Domain id=1 name='vgpu-win10'
uuid=916c5c36-0437-11e7-a23d-830ed1295d00 is tainted: high-privileges
2017-03-26 23:28:58.010+: 2886: warning :
virDomainAuditHostdev:456 : Unexpected hostdev type while encoding
audit message: 4
Domain vgpu-win10 started


2. None rooted
virsh -c qemu:///session
Welcome to lt-virsh, the virtualization interactive terminal.


The above line makes me think that you're mixing up "unprivileged
libvirtd" with "unprivileged qemu".

When you connect to virsh with "virsh -c qemu:///session" you are using
an unprivileged copy of libvirtd started for your specific uid, and that
libvirtd will:

1) not do any of the uid/permission/selinux/apparmor changes to the
files/devices that will be used by the qemu process. (because it can't)

2) try to modify the locked memory limit for the qemu process, but
likely fail because it needs more than the user's default limit. (I see
below that you ran into this).

3) run qemu as the same unprivileged user.


When you connect to virsh with the default URL (qemu:///system) you will
connect to the system instance of libvirtd, which is running as root. It
will:

1) modify uid/permissions/selinux/apparmor settings of any files/devices
according to the "user" setting in /etc/libvirt/qemu.conf.

and after forking the qemu process:

2) modify the locked memory limit to accommodate the needs of any
assigned devices and

3) change the uid of the qemu process to the "user" setting from
qemu.conf and drop all privileges

(in the case that the "user" in qemu.conf is set to root, then step 3
doesn't happen).

It sounds like you are using an "unprivileged libvirtd" in your tests,
which will create the need to chown the various device files and
manually change the ulimit for the login session that is running "virsh
-c qemu:///session" (and thus starting up the unprivileged libvirtd
which gets started on demand).

The more common scenario is to use virsh -c qemu:///system (or simply
run virsh as root and not add the URL so that the default is used), and
to leave the qemu user set to "qemu" (or in some distros I think it is
set to "kvm" by default).
thanks explain all of these,  this is so big help to better 
understanding the processes of libvirt and what problem i'm encounter,

thanks, very much!

Regards
Yongli He



virsh # define ./libvirt/vgpu-win10.xml
Domain vgpu-win10 defined from ./libvirt/vgpu-win10.xml

virsh # start vgpu-win10
2017-03-26 23:38:11.220+: 2882: warning : qemuDomainObjTaint:4155
: Domain id=4 name='vgpu-win10'
uuid=916c5c36-0437-11e7-a23d-830ed1295d00 is tainted: high-privileges
2017-03-26 23:38:12.356+: 2882: warning :
virDomainAuditHostdev:456 : Unexpected hostdev type while encoding
audit message: 4
Domain vgpu-win10 started

Please ignore above none rooted testing result, my fault. the proper
test given following result:

to successfully starting a non rooted vm, the following operation needed:
1.change the ownership/access right of the mdev corresponding vfio
sudo chown ubuntu:ubuntu /dev/vfio/0

2. set a correct ulimit -l  for the vm
sudo sh -c "ulimit -l 3074424832 && exec su $LOGNAME"

otherwise, it running into the following error:
virsh # start vgpu-win10
  internal error: Process exited prior to exec: libvirt:  error : cannot
limit locked memory to 3074424832: Operation not permitted

This is to be expected - both of these extra steps are also needed if
you try to assign a standard PCI device using VFIO using unprivileged
libvirtd. This is the best that can be expected without any component
having root privileges.

If you run the same test using qemu:///system, both of these should be
taken care of automatically.


my testing bed is Ubuntu 14.04, there is a similar bug ever reported:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1276719

The original report (filed 2.5 years ago, and resolved soon after) was
due to apparmor not doing the right stuff to the necessary files in
sysfs. Many later comments and error messages were from people who were
using the tools incorrectly (e.g. using  to manually
add "-device vfio-pci" args to the qemu process, making it impossible
for libvirt to recognize that it must perform steps 2 & 3 listed above.


I could not make sure if there is special requirements  run virsh
directly from the source tree using the ./run scripts. fix me.

I'm fairly certain the reason you're nee

Re: [libvirt] [PATCH v2 4/5] qemu: Enforce ACPI, UEFI requirements

2017-03-29 Thread John Ferlan



On 03/29/2017 10:08 AM, Andrea Bolognani wrote:
> Depending on the architecture, requirements for ACPI and UEFI can
> be different; more specifically, while on x86 UEFI requires ACPI,
> on aarch64 it's the other way around.
> 
> Enforce these requirements when validating the domain, and make
> the error message more accurate by mentioning that they're not
> necessarily applicable to all architectures.
> 
> Several aarch64 test cases had to be tweaked because they would
> have failed the validation step otherwise.
> ---
>  src/qemu/qemu_command.c  | 20 
> 
>  src/qemu/qemu_domain.c   | 20 
> 
>  .../qemuxml2argv-aarch64-aavmf-virtio-mmio.args  |  1 +
>  .../qemuxml2argv-aarch64-aavmf-virtio-mmio.xml   |  1 -
>  .../qemuxml2argv-aarch64-cpu-passthrough.args|  1 +
>  .../qemuxml2argv-aarch64-cpu-passthrough.xml |  1 -
>  .../qemuxml2argv-aarch64-video-virtio-gpu-pci.args   |  1 +
>  .../qemuxml2argv-aarch64-video-virtio-gpu-pci.xml|  3 ---
>  ...xml2argv-aarch64-virt-2.6-virtio-pci-default.args |  1 +
>  ...uxml2argv-aarch64-virt-2.6-virtio-pci-default.xml |  1 -
>  .../qemuxml2argv-aarch64-virt-default-nic.args   |  1 +
>  .../qemuxml2argv-aarch64-virt-default-nic.xml|  3 ---
>  .../qemuxml2argv-aarch64-virt-virtio.args|  1 +
>  .../qemuxml2argv-aarch64-virt-virtio.xml |  1 -
>  .../qemuxml2argv-aarch64-virtio-pci-default.args |  1 +
>  .../qemuxml2argv-aarch64-virtio-pci-default.xml  |  1 -
>  ...xml2argv-aarch64-virtio-pci-manual-addresses.args |  1 +
>  ...uxml2argv-aarch64-virtio-pci-manual-addresses.xml |  1 -
>  .../qemuxml2argv-balloon-mmio-deflate.args   |  1 +
>  .../qemuxml2argv-balloon-mmio-deflate.xml|  1 -
>  .../qemuxml2xmlout-aarch64-aavmf-virtio-mmio.xml |  1 -
>  .../qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml  |  1 -
>  .../qemuxml2xmlout-aarch64-virtio-pci-default.xml|  1 -
>  ...ml2xmlout-aarch64-virtio-pci-manual-addresses.xml |  1 -
>  24 files changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 64d2d71..5cf383a 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -9324,18 +9324,16 @@ qemuBuildRedirdevCommandLine(virLogManagerPtr 
> logManager,
>  }
>  
>  
> -static int
> +static void
>  qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
> - virDomainDefPtr def,
> - virQEMUCapsPtr qemuCaps)
> + virDomainDefPtr def)
>  {
> -int ret = -1;
>  virDomainLoaderDefPtr loader = def->os.loader;
>  virBuffer buf = VIR_BUFFER_INITIALIZER;
>  int unit = 0;
>  
>  if (!loader)
> -return 0;
> +return;
>  
>  switch ((virDomainLoader) loader->type) {
>  case VIR_DOMAIN_LOADER_TYPE_ROM:
> @@ -9344,12 +9342,6 @@ qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
>  break;
>  
>  case VIR_DOMAIN_LOADER_TYPE_PFLASH:
> -if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_ACPI) &&
> -def->features[VIR_DOMAIN_FEATURE_ACPI] != 
> VIR_TRISTATE_SWITCH_ON) {
> -virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> -   _("ACPI must be enabled in order to use UEFI"));
> -goto cleanup;
> -}
>  
>  if (loader->secure == VIR_TRISTATE_BOOL_YES) {
>  virCommandAddArgList(cmd,
> @@ -9387,10 +9379,7 @@ qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
>  break;
>  }
>  
> -ret = 0;
> - cleanup:
>  virBufferFreeAndReset(&buf);
> -return ret;
>  }
>  
>  
> @@ -9827,8 +9816,7 @@ qemuBuildCommandLine(virQEMUDriverPtr driver,
>  if (qemuBuildCpuCommandLine(cmd, driver, def, qemuCaps) < 0)
>  goto error;
>  
> -if (qemuBuildDomainLoaderCommandLine(cmd, def, qemuCaps) < 0)
> -goto error;
> +qemuBuildDomainLoaderCommandLine(cmd, def);
>  
>  if (!migrateURI && !snapshot && qemuDomainAlignMemorySizes(def) < 0)
>  goto error;
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 458bb5f..e41e8e4 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -2884,6 +2884,26 @@ qemuDomainDefValidate(const virDomainDef *def,
>  goto cleanup;
>  }
>  
> +/* On x86, UEFI requires ACPI */
> +if (def->os.loader &&
> +def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH &&
> +ARCH_IS_X86(def->os.arch) &&
> +def->features[VIR_DOMAIN_FEATURE_ACPI] != VIR_TRISTATE_SWITCH_ON) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> +   _("UEFI requires ACPI on this architecture"));
> +goto cleanup;
> +}
> +
> +/* On aarch64, ACPI requires UEFI */
> +if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON &&
> +def->os

Re: [libvirt] [PATCH v2 5/5] tests: Test ACPI, UEFI requirements

2017-03-29 Thread John Ferlan



On 03/29/2017 10:08 AM, Andrea Bolognani wrote:
> Make sure every combination of ACPI and UEFI works, or fails to
> work, as expected.
> ---
>  .../qemuxml2argv-aarch64-acpi-nouefi.args  | 22 +
>  .../qemuxml2argv-aarch64-acpi-nouefi.xml   | 22 +
>  .../qemuxml2argv-aarch64-acpi-uefi.args| 22 +
>  .../qemuxml2argv-aarch64-acpi-uefi.xml | 21 
>  .../qemuxml2argv-aarch64-noacpi-nouefi.args| 22 +
>  .../qemuxml2argv-aarch64-noacpi-nouefi.xml | 19 ++
>  .../qemuxml2argv-aarch64-noacpi-uefi.args  | 23 
> ++
>  .../qemuxml2argv-aarch64-noacpi-uefi.xml   | 18 +
>  .../qemuxml2argv-q35-acpi-nouefi.args  | 21 
>  .../qemuxml2argv-q35-acpi-nouefi.xml   | 22 +
>  .../qemuxml2argv-q35-acpi-uefi.args| 22 +
>  .../qemuxml2argv-q35-acpi-uefi.xml | 21 
>  .../qemuxml2argv-q35-noacpi-nouefi.args| 22 +
>  .../qemuxml2argv-q35-noacpi-nouefi.xml | 19 ++
>  .../qemuxml2argv-q35-noacpi-uefi.xml   | 18 +
>  tests/qemuxml2argvtest.c   | 14 +
>  16 files changed, 328 insertions(+)
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.args
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.xml
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.args
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.xml
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-nouefi.args
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-nouefi.xml
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-uefi.args
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-uefi.xml
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-nouefi.args
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-nouefi.xml
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-uefi.args
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-uefi.xml
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-noacpi-nouefi.args
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-noacpi-nouefi.xml
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-noacpi-uefi.xml
> 

ACK

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 2/5] tests: Initialize basic capabilities properly

2017-03-29 Thread John Ferlan



On 03/29/2017 10:08 AM, Andrea Bolognani wrote:
> The capabilities used in test cases should match those used
> during normal operation for the tests to make any sense.

Could you add just a bit of text about why all -no-acpi is removed
(mostly) and why -no-hpet is added to a couple?

It's essentially the comment from the subsequent patch:

"-no-acpi is not supported on non-x86 even if qemu reports it in -help",
so all non-x64 .args file need to remove

Still not sure I understand why the no-hpet got added, but I suppose
they're necessary. And only a couple of outputs have it...  Guess it
depends on what else is defined...

Should have said something in v1...

ACK

John

> ---
>  src/qemu/qemu_capabilities.c  | 2 +-
>  src/qemu/qemu_capabilities.h  | 2 ++
>  tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v2.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-console-virtio-ccw.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-console-virtio-s390.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw-many.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-s390.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-ccw.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-fs9p-ccw.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi-ccw.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-hugepages-numa.args   | 1 +
>  tests/qemuxml2argvdata/qemuxml2argv-iothreads-disk-virtio-ccw.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-iothreads-virtio-scsi-ccw.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-off-cap.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-off-caps.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-on-cap.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-on-caps.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-off-cap.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-off-caps.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-on-cap.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-on-caps.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-keywrap-none-caps.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-machine-keywrap-none.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-ppc64-nonuma.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-net-virtio-ccw.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-net-virtio-s390.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-compat.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-le.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-panic-missing.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-panic-no-address.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-default.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-kbd.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-multi.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args  | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args   | 1 +
>  .../qemuxml2argv-s390-allow-bogus-usb-controller.args | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-s390-allow-bogus-usb-none.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-s390-panic-missing.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-s390-panic-no-address.args| 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-virtio-rng-ccw.args   | 1 -
>  tests/qemuxml2argvdata/qemuxml2argv-watchdog-diag288.args | 1 -
>  tests/qemuxml2argvtest.c

Re: [libvirt] [PATCH v2 3/5] qemu: Advertise ACPI support for aarch64 guests

2017-03-29 Thread John Ferlan



On 03/29/2017 10:08 AM, Andrea Bolognani wrote:
> So far, libvirt has assumed that only x86 supports ACPI,
> but that's inaccurate since aarch64 supports it too.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
> ---
>  src/qemu/qemu_capabilities.c   | 28 
> --
>  .../caps_2.6.0-gicv2.aarch64.xml   |  1 +
>  .../caps_2.6.0-gicv3.aarch64.xml   |  1 +
>  .../qemuxml2argv-aarch64-gic-host.args |  1 +
>  .../qemuxml2argv-aarch64-gic-v2.args   |  1 +
>  .../qemuxml2argv-aarch64-gic-v3.args   |  1 +
>  6 files changed, 26 insertions(+), 7 deletions(-)
> 

ACK

John


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 1/5] qemu: Split virQEMUCapsInitArchQMPBasic()

2017-03-29 Thread John Ferlan



On 03/29/2017 10:08 AM, Andrea Bolognani wrote:
> Instead of having a single function that probes the
> architecture from the monitor and then sets a bunch of
> basic capabilities based on it, have a separate function
> for each part: virQEMUCapsInitQMPArch() only sets the
> architecture, and virQEMUCapsInitQMPBasicArch() only sets
> the capabilities.
> 
> This split will be useful later on, when we will want to
> set basic capabilities from the test suite without having
> to go through the pain of mocking the monitor.
> ---
> This is 99% pure code motion; however, an early 'return -1'
> has been converted to the equivalent 'goto cleanup'.
> 
>  src/qemu/qemu_capabilities.c | 42 +++---
>  1 file changed, 31 insertions(+), 11 deletions(-)
> 

ACK,

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] [libvirt-php] fix libvirt_stream_send/libvirt_stream_recv

2017-03-29 Thread Vasiliy Tolstov

When php disable call pass time by reference this breaks libvirt_stream_recv
and also bring more memory allocations from zend engine.

Vasiliy Tolstov (1):
  fix libvirt_stream_send/libvirt_stream_recv

 src/libvirt-php.c | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] [libvirt-php] fix libvirt_stream_send/libvirt_stream_recv

2017-03-29 Thread Vasiliy Tolstov

Signed-off-by: Vasiliy Tolstov 
---
 src/libvirt-php.c | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/src/libvirt-php.c b/src/libvirt-php.c
index e8384795d635..4e088e746281 100644
--- a/src/libvirt-php.c
+++ b/src/libvirt-php.c
@@ -178,9 +178,15 @@ ZEND_ARG_INFO(0, stats)
 ZEND_ARG_INFO(0, flags)
 ZEND_END_ARG_INFO()
 
-ZEND_BEGIN_ARG_INFO_EX(arginfo_libvirt_stream_send, 0, 0, 2)
+ZEND_BEGIN_ARG_INFO_EX(arginfo_libvirt_stream_send, 0, 1, 2)
 ZEND_ARG_INFO(0, conn)
-ZEND_ARG_INFO(0, data)
+ZEND_ARG_INFO(1, data)
+ZEND_ARG_INFO(0, len)
+ZEND_END_ARG_INFO()
+
+ZEND_BEGIN_ARG_INFO_EX(arginfo_libvirt_stream_recv, 0, 1, 2)
+ZEND_ARG_INFO(0, conn)
+ZEND_ARG_INFO(1, data)
 ZEND_ARG_INFO(0, len)
 ZEND_END_ARG_INFO()
 
@@ -595,7 +601,7 @@ static zend_function_entry libvirt_functions[] = {
 PHP_FE(libvirt_stream_abort, arginfo_libvirt_conn)
 PHP_FE(libvirt_stream_finish,arginfo_libvirt_conn)
 PHP_FE(libvirt_stream_send,  arginfo_libvirt_stream_send)
-PHP_FE(libvirt_stream_recv,  arginfo_libvirt_stream_send)
+PHP_FE(libvirt_stream_recv,  arginfo_libvirt_stream_recv)
 /* Domain functions */
 PHP_FE(libvirt_domain_new,   arginfo_libvirt_domain_new)
 PHP_FE(libvirt_domain_new_get_vnc,   arginfo_libvirt_void)
@@ -4509,7 +4515,7 @@ PHP_FUNCTION(libvirt_stream_finish)
 /*
  * Function name:   libvirt_stream_recv
  * Since version:   0.5.0
- * Description: Function is used to close stream from libvirt conn
+ * Description: Function is used to recv from stream via libvirt conn
  * Arguments:   @res [resource]: libvirt stream resource from 
libvirt_stream_create()
  *  @data [string]: buffer
  *  @len [int]: amout of data to recieve
@@ -4518,8 +4524,8 @@ PHP_FUNCTION(libvirt_stream_finish)
 PHP_FUNCTION(libvirt_stream_recv)
 {
 zval *zstream, *zbuf;
-char *recv_buf;
 php_libvirt_stream *stream = NULL;
+char *recv_buf = NULL;
 int retval = -1;
 zend_long length = 0;
 
@@ -4534,31 +4540,24 @@ PHP_FUNCTION(libvirt_stream_recv)
 
 retval = virStreamRecv(stream->stream, recv_buf, length);
 if (retval < 0) {
-efree(recv_buf);
-zval_dtor(zbuf);
-ZVAL_NULL(zbuf);
+  zval_dtor(zbuf);
+  ZVAL_NULL(zbuf);
 } else {
 recv_buf[retval] = '\0';
-#if PHP_MAJOR_VERSION >= 7
-ZVAL_STRINGL(zbuf, recv_buf, retval);
-efree(recv_buf);
-#else
-ZVAL_STRINGL(zbuf, recv_buf, retval, 0);
-#endif
+VIRT_ZVAL_STRINGL(zbuf, recv_buf, retval);
 }
 
 if (retval == -1) {
 set_error("Cannot recv from stream" TSRMLS_CC);
-RETURN_LONG(retval);
 }
-
+efree(recv_buf);
 RETURN_LONG(retval);
 }
 
 /*
  * Function name:   libvirt_stream_send
  * Since version:   0.5.0
- * Description: Function is used to close stream from libvirt conn
+ * Description: Function is used to send to stream via libvirt conn
  * Arguments:   @res [resource]: libvirt stream resource from 
libvirt_stream_create()
  *  @data [string]: buffer
  *  @length [int]: amout of data to send
@@ -4571,7 +4570,6 @@ PHP_FUNCTION(libvirt_stream_send)
 int retval = -1;
 zend_long length = 0;
 char *cstr;
-//int cstrlen;
 
 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rz|l", &zstream, 
&zbuf, &length) == FAILURE)
 RETURN_LONG(retval);
@@ -4580,12 +4578,10 @@ PHP_FUNCTION(libvirt_stream_send)
 RETURN_LONG(retval);
 
 cstr = Z_STRVAL_P(zbuf);
-//cstrlen = Z_STRLEN_P(zbuf);
 
 retval = virStreamSend(stream->stream, cstr, length);
 if (retval == -1) {
 set_error("Cannot send to stream" TSRMLS_CC);
-RETURN_LONG(retval);
 }
 
 RETURN_LONG(retval);
-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] docs: document bhyve UEFI support

2017-03-29 Thread Roman Bogorodskiy

  Laine Stump wrote:

> On 03/27/2017 12:33 PM, Roman Bogorodskiy wrote:
> >  - Add a news entry
> >  - Update the driver page with documentation of the new options
> >and some examples
> > ---
> >  docs/drvbhyve.html.in | 94 
> > +++
> >  docs/news.xml | 13 +++
> >  2 files changed, 107 insertions(+)
> 
> ACK. (I didn't check the content carefully, but did make sure that make
> syntax-check and make check didn't complain).

Pushed, thanks!

Roman Bogorodskiy


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] testing volDownload and volUpload different md5 on source and dest for qcow2

2017-03-29 Thread Vasiliy Tolstov

Hi. I'm fix libvirt php binding to properly recv from stream and after
that test volume download and volume upload functions. And see, that
in case of raw image md5sum on src and on dst is equal.
But in case of qcow - phisical size of image is different and md5sum
does not equal.
Why this can happening?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] qemu: Enforce ACPI, UEFI requirements

2017-03-29 Thread John Ferlan



On 03/29/2017 10:12 AM, Andrea Bolognani wrote:
> On Mon, 2017-03-27 at 08:03 -0400, John Ferlan wrote:
>>> @@ -6252,9 +6252,23 @@ qemuBuildPMCommandLine(virCommandPtr cmd,
>>>   virCommandAddArg(cmd, "-no-shutdown");
>>>   }
>>>   
>>> +/* Architectures that support ACPI also support -no-acpi as a way
>>> + * of turning it off, and vice versa */
>>>   if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_ACPI)) {
>>> +
>>> +/* ACPI is off unless explicitly turned on */
>>>   if (def->features[VIR_DOMAIN_FEATURE_ACPI] != 
>>> VIR_TRISTATE_SWITCH_ON)
>>>   virCommandAddArg(cmd, "-no-acpi");
>>> +
>>> +/* aarch64 requires UEFI to be in use for ACPI to work */
>>> +if (def->features[VIR_DOMAIN_FEATURE_ACPI] == 
>>> VIR_TRISTATE_SWITCH_ON &&
>>> +def->os.arch == VIR_ARCH_AARCH64 &&
>>> +(!def->os.loader ||
>>> + def->os.loader->type != VIR_DOMAIN_LOADER_TYPE_PFLASH)) {
>>> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>>> +   _("ACPI requires UEFI on this architecture"));
>>> +return -1;
>>> +}
>>  
>> Why isn't this check in qemuDomainDefPostParse?
>>  
>> Avoids errors in command line building which IIRC was something where
>> there was an "effort" to avoid in favor of "earlier" checking.
> 
> Good point.
> 
> I've actually moved both checks to qemuDomainDefValidate()
> rather than qemuDomainDefPostParse(), so that we can prevent
> users from defining or starting guests that don't follow the
> requirements without losing existing guests.

As long we don't make a guest disappear then we're good.

> 
> I've just posted [v2], if you feel like taking a look :)
> 

I'll look later today.

John
> 
> [v2] https://www.redhat.com/archives/libvir-list/2017-March/msg01531.html
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 00/14] Introduce vGPU mdev framework to libvirt

2017-03-29 Thread Laine Stump

On 03/28/2017 10:05 PM, yonglihe wrote:
> On 2017年03月27日 15:42, yonglihe wrote:
>>
>> Verify Summary:
>> * the none rooted mode starting a high-privileges VM actually.
>>
>> The configurations is source generated default value except tls disabled.
>>
>>
>> 1. rooted
>>
>> virsh define ./libvirt/vgpu-win10.xml
>> Domain vgpu-win10 defined from ./libvirt/vgpu-win10.xml
>>
>> ubuntu@z-nuc-11:~/vgpu-meta/libvirt-stage$ virsh start vgpu-win10
>> 2017-03-26 23:28:57.385+: 2886: info : libvirt version: 3.2.0
>> 2017-03-26 23:28:57.385+: 2886: info : hostname: z-nuc-11.maas
>> 2017-03-26 23:28:57.385+: 2886: warning : qemuDomainObjTaint:4155
>> : Domain id=1 name='vgpu-win10'
>> uuid=916c5c36-0437-11e7-a23d-830ed1295d00 is tainted: high-privileges
>> 2017-03-26 23:28:58.010+: 2886: warning :
>> virDomainAuditHostdev:456 : Unexpected hostdev type while encoding
>> audit message: 4
>> Domain vgpu-win10 started
>>
>>
>> 2. None rooted
>> virsh -c qemu:///session
>> Welcome to lt-virsh, the virtualization interactive terminal.

The above line makes me think that you're mixing up "unprivileged
libvirtd" with "unprivileged qemu".

When you connect to virsh with "virsh -c qemu:///session" you are using
an unprivileged copy of libvirtd started for your specific uid, and that
libvirtd will:

1) not do any of the uid/permission/selinux/apparmor changes to the
files/devices that will be used by the qemu process. (because it can't)

2) try to modify the locked memory limit for the qemu process, but
likely fail because it needs more than the user's default limit. (I see
below that you ran into this).

3) run qemu as the same unprivileged user.

When you connect to virsh with the default URL (qemu:///system) you will
connect to the system instance of libvirtd, which is running as root. It
will:

1) modify uid/permissions/selinux/apparmor settings of any files/devices
according to the "user" setting in /etc/libvirt/qemu.conf.

and after forking the qemu process:

2) modify the locked memory limit to accommodate the needs of any
assigned devices and

3) change the uid of the qemu process to the "user" setting from
qemu.conf and drop all privileges

(in the case that the "user" in qemu.conf is set to root, then step 3
doesn't happen).

It sounds like you are using an "unprivileged libvirtd" in your tests,
which will create the need to chown the various device files and
manually change the ulimit for the login session that is running "virsh
-c qemu:///session" (and thus starting up the unprivileged libvirtd
which gets started on demand).

The more common scenario is to use virsh -c qemu:///system (or simply
run virsh as root and not add the URL so that the default is used), and
to leave the qemu user set to "qemu" (or in some distros I think it is
set to "kvm" by default).

>>
>> virsh # define ./libvirt/vgpu-win10.xml
>> Domain vgpu-win10 defined from ./libvirt/vgpu-win10.xml
>>
>> virsh # start vgpu-win10
>> 2017-03-26 23:38:11.220+: 2882: warning : qemuDomainObjTaint:4155
>> : Domain id=4 name='vgpu-win10'
>> uuid=916c5c36-0437-11e7-a23d-830ed1295d00 is tainted: high-privileges
>> 2017-03-26 23:38:12.356+: 2882: warning :
>> virDomainAuditHostdev:456 : Unexpected hostdev type while encoding
>> audit message: 4
>> Domain vgpu-win10 started
> Please ignore above none rooted testing result, my fault. the proper
> test given following result:
> 
> to successfully starting a non rooted vm, the following operation needed:
> 1.change the ownership/access right of the mdev corresponding vfio
>sudo chown ubuntu:ubuntu /dev/vfio/0
> 
> 2. set a correct ulimit -l  for the vm
> sudo sh -c "ulimit -l 3074424832 && exec su $LOGNAME"
> 
> otherwise, it running into the following error:
> virsh # start vgpu-win10
>  internal error: Process exited prior to exec: libvirt:  error : cannot
> limit locked memory to 3074424832: Operation not permitted

This is to be expected - both of these extra steps are also needed if
you try to assign a standard PCI device using VFIO using unprivileged
libvirtd. This is the best that can be expected without any component
having root privileges.

If you run the same test using qemu:///system, both of these should be
taken care of automatically.

> 
> my testing bed is Ubuntu 14.04, there is a similar bug ever reported:
> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1276719

The original report (filed 2.5 years ago, and resolved soon after) was
due to apparmor not doing the right stuff to the necessary files in
sysfs. Many later comments and error messages were from people who were
using the tools incorrectly (e.g. using  to manually
add "-device vfio-pci" args to the qemu process, making it impossible
for libvirt to recognize that it must perform steps 2 & 3 listed above.

> 
> I could not make sure if there is special requirements  run virsh
> directly from the source tree using the ./run scripts. fix me.

I'm fairly certain the reason you're needing to perform those two ex

Re: [libvirt] [python PATCH 0/2] Fix event comment and add handler for block threshold

2017-03-29 Thread Eric Blake

On 03/29/2017 10:00 AM, Peter Krempa wrote:
> Peter Krempa (2):
>   event: fix comment for _dispatchDomainEventMetadataChangeCallback
>   event: Add handler for block threshold event

ACK

> 
>  examples/event-test.py |  4 +++
>  libvirt-override-virConnect.py | 11 +++-
>  libvirt-override.c | 62 
> ++
>  3 files changed, 76 insertions(+), 1 deletion(-)
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [python PATCH 1/2] event: fix comment for _dispatchDomainEventMetadataChangeCallback

2017-03-29 Thread Peter Krempa

The comment was copied from the device removal failed event.
---
 libvirt-override-virConnect.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libvirt-override-virConnect.py b/libvirt-override-virConnect.py
index bcd72ac..35009bb 100644
--- a/libvirt-override-virConnect.py
+++ b/libvirt-override-virConnect.py
@@ -244,7 +244,7 @@
 return 0

 def _dispatchDomainEventMetadataChangeCallback(self, dom, mtype, nsuri, 
cbData):
-"""Dispatches event to python user domain device removal failed event 
callbacks
+"""Dispatches event to python user domain metadata change event 
callbacks
 """
 cb = cbData["cb"]
 opaque = cbData["opaque"]
-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [python PATCH 0/2] Fix event comment and add handler for block threshold

2017-03-29 Thread Peter Krempa

Peter Krempa (2):
  event: fix comment for _dispatchDomainEventMetadataChangeCallback
  event: Add handler for block threshold event

 examples/event-test.py |  4 +++
 libvirt-override-virConnect.py | 11 +++-
 libvirt-override.c | 62 ++
 3 files changed, 76 insertions(+), 1 deletion(-)

-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: domain: Properly lookup top of chain in qemuDomainGetStorageSourceByDevstr

2017-03-29 Thread Eric Blake

On 03/29/2017 09:58 AM, Peter Krempa wrote:
> When idx is 0 virStorageFileChainLookup returns the base (bottom) of the
> backing chain rather than the top. This is expected by the callers of
> qemuDomainGetStorageSourceByDevstr.
> 
> Add a special case for idx == 0
> ---
> With this you are not able to specify the top image of a disk when using
> virDomainSetBlockThreshold in qemu.
> 
>  src/qemu/qemu_domain.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

ACK

> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 458bb5f9a..589eb1889 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -8605,7 +8605,10 @@ qemuDomainGetStorageSourceByDevstr(const char *devstr,
>  goto cleanup;
>  }
> 
> -src = virStorageFileChainLookup(disk->src, NULL, NULL, idx, NULL);
> +if (idx == 0)
> +src = disk->src;
> +else
> +src = virStorageFileChainLookup(disk->src, NULL, NULL, idx, NULL);
> 
>   cleanup:
>  VIR_FREE(target);
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/3] qemuMonitorCPUModelInfo: Add support for non-migratable features

2017-03-29 Thread Jiri Denemark

QEMU is able to tell us whether a CPU feature would block migration or
not. This patch adds support for storing such features in
qemuMonitorCPUModelInfo.

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_capabilities.c | 39 +---
 src/qemu/qemu_monitor.c  |  2 ++
 src/qemu/qemu_monitor.h  |  2 ++
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml  |  2 +-
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml |  4 +--
 5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index f51141b99..446c15f92 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3272,6 +3272,7 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
 int ret = -1;
 size_t i;
 int n;
+int val;
 
 if (virtType == VIR_DOMAIN_VIRT_KVM)
 hostCPUNode = virXPathNode("./hostCPU[@type='kvm']", ctxt);
@@ -3293,6 +3294,15 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
 goto cleanup;
 }
 
+if (!(str = virXMLPropString(hostCPUNode, "migratability")) ||
+(val = virTristateBoolTypeFromString(str)) <= 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("invalid migratability value for host CPU model"));
+goto cleanup;
+}
+hostCPU->migratability = val == VIR_TRISTATE_BOOL_YES;
+VIR_FREE(str);
+
 ctxt->node = hostCPUNode;
 
 if ((n = virXPathNodeSet("./property", ctxt, &nodes)) > 0) {
@@ -3303,7 +3313,6 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
 
 for (i = 0; i < n; i++) {
 qemuMonitorCPUPropertyPtr prop = hostCPU->props + i;
-int type;
 
 ctxt->node = nodes[i];
 
@@ -3315,7 +3324,7 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
 }
 
 if (!(str = virXMLPropString(ctxt->node, "type")) ||
-(type = qemuMonitorCPUPropertyTypeFromString(str)) < 0) {
+(val = qemuMonitorCPUPropertyTypeFromString(str)) < 0) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing or invalid CPU model property type "
  "in QEMU capabilities cache"));
@@ -3323,7 +3332,7 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
 }
 VIR_FREE(str);
 
-prop->type = type;
+prop->type = val;
 switch (prop->type) {
 case QEMU_MONITOR_CPU_PROPERTY_BOOLEAN:
 if (virXPathBoolean("./@value='true'", ctxt))
@@ -3355,6 +3364,19 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
 case QEMU_MONITOR_CPU_PROPERTY_LAST:
 break;
 }
+
+if ((str = virXMLPropString(ctxt->node, "migratable"))) {
+if ((val = virTristateBoolTypeFromString(str)) <= 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("unknown migratable value for '%s' host "
+ "CPU model property"),
+   prop->name);
+goto cleanup;
+}
+
+prop->migratable = val;
+VIR_FREE(str);
+}
 }
 }
 
@@ -3707,8 +3729,10 @@ virQEMUCapsFormatHostCPUModelInfo(virQEMUCapsPtr 
qemuCaps,
 if (!model)
 return;
 
-virBufferAsprintf(buf, "\n",
-  typeStr, model->name);
+virBufferAsprintf(buf,
+  "\n",
+  typeStr, model->name,
+  model->migratability ? "yes" : "no");
 virBufferAdjustIndent(buf, 2);
 
 for (i = 0; i < model->nprops; i++) {
@@ -3735,6 +3759,11 @@ virQEMUCapsFormatHostCPUModelInfo(virQEMUCapsPtr 
qemuCaps,
 case QEMU_MONITOR_CPU_PROPERTY_LAST:
 break;
 }
+
+if (prop->migratable > 0)
+virBufferAsprintf(buf, " migratable='%s'",
+  virTristateBoolTypeToString(prop->migratable));
+
 virBufferAddLit(buf, "/>\n");
 }
 
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 78d9cb752..e9ba5fdea 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -3747,12 +3747,14 @@ qemuMonitorCPUModelInfoCopy(const 
qemuMonitorCPUModelInfo *orig)
 if (VIR_STRDUP(copy->name, orig->name) < 0)
 goto error;
 
+copy->migratability = orig->migratability;
 copy->nprops = orig->nprops;
 
 for (i = 0; i < orig->nprops; i++) {
 if (VIR_STRDUP(copy->props[i].name, orig->props[i].name) < 0)
 goto error;
 
+copy->props[i].migratable = orig->props[i].migratable;
 copy->props[i].type = orig->props[i].type;
 switch (orig->props[i].type) {
 case QEMU_MONITOR_CPU_PROPERTY_BOOLEAN:
diff --git a/src/qemu/qemu_mon

[libvirt] [python PATCH 2/2] event: Add handler for block threshold event

2017-03-29 Thread Peter Krempa

Unfortunately python doesn't generate those.
---
 examples/event-test.py |  4 +++
 libvirt-override-virConnect.py |  9 ++
 libvirt-override.c | 62 ++
 3 files changed, 75 insertions(+)

diff --git a/examples/event-test.py b/examples/event-test.py
index d5af33c..a1105a3 100755
--- a/examples/event-test.py
+++ b/examples/event-test.py
@@ -541,6 +541,9 @@ def myDomainEventDeviceRemovalFailedCallback(conn, dom, 
dev, opaque):
 def myDomainEventMetadataChangeCallback(conn, dom, mtype, nsuri, opaque):
 print("myDomainEventMetadataChangeCallback: Domain %s(%s) changed metadata 
mtype=%d nsuri=%s" % (
 dom.name(), dom.ID(), mtype, nsuri))
+def myDomainEventBlockThresholdCallback(conn, dom, dev, path, threshold, 
excess, opaque):
+print("myDomainEventBlockThresholdCallback: Domain %s(%s) block device 
%s(%s) threshold %d exceeded by %d" % (
+dom.name(), dom.ID(), dev, path, threshold, excess))

 ##
 # Network events
@@ -710,6 +713,7 @@ def main():
 vc.domainEventRegisterAny(None, libvirt.VIR_DOMAIN_EVENT_ID_JOB_COMPLETED, 
myDomainEventJobCompletedCallback, None)
 vc.domainEventRegisterAny(None, 
libvirt.VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED, 
myDomainEventDeviceRemovalFailedCallback, None)
 vc.domainEventRegisterAny(None, 
libvirt.VIR_DOMAIN_EVENT_ID_METADATA_CHANGE, 
myDomainEventMetadataChangeCallback, None)
+vc.domainEventRegisterAny(None, 
libvirt.VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD, 
myDomainEventBlockThresholdCallback, None)

 vc.networkEventRegisterAny(None, libvirt.VIR_NETWORK_EVENT_ID_LIFECYCLE, 
myNetworkEventLifecycleCallback, None)

diff --git a/libvirt-override-virConnect.py b/libvirt-override-virConnect.py
index 35009bb..f26e65a 100644
--- a/libvirt-override-virConnect.py
+++ b/libvirt-override-virConnect.py
@@ -252,6 +252,15 @@
 cb(self, virDomain(self, _obj=dom), mtype, nsuri, opaque)
 return 0

+def _dispatchDomainEventBlockThresholdCallback(self, dom, dev, path, 
threshold, excess, cbData):
+"""Dispatches event to python user domain block device threshold event 
callbacks
+"""
+cb = cbData["cb"]
+opaque = cbData["opaque"]
+
+cb(self, virDomain(self, _obj=dom), dev, path, threshold, excess, 
opaque)
+return 0
+
 def domainEventDeregisterAny(self, callbackID):
 """Removes a Domain Event Callback. De-registering for a
domain callback will disable delivery of this event type """
diff --git a/libvirt-override.c b/libvirt-override.c
index 9e40f00..93c7ef0 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
@@ -6932,6 +6932,63 @@ 
libvirt_virConnectDomainEventMetadataChangeCallback(virConnectPtr conn ATTRIBUTE
 }
 #endif /* VIR_DOMAIN_EVENT_ID_METADATA_CHANGE */

+#ifdef VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD
+static int
+libvirt_virConnectDomainEventBlockThresholdCallback(virConnectPtr conn 
ATTRIBUTE_UNUSED,
+virDomainPtr dom,
+const char *dev,
+const char *path,
+unsigned long long 
threshold,
+unsigned long long excess,
+void *opaque)
+{
+PyObject *pyobj_cbData = (PyObject*)opaque;
+PyObject *pyobj_dom;
+PyObject *pyobj_ret = NULL;
+PyObject *pyobj_conn;
+PyObject *dictKey;
+int ret = -1;
+
+LIBVIRT_ENSURE_THREAD_STATE;
+
+if (!(dictKey = libvirt_constcharPtrWrap("conn")))
+goto cleanup;
+pyobj_conn = PyDict_GetItem(pyobj_cbData, dictKey);
+Py_DECREF(dictKey);
+
+/* Create a python instance of this virDomainPtr */
+virDomainRef(dom);
+if (!(pyobj_dom = libvirt_virDomainPtrWrap(dom))) {
+virDomainFree(dom);
+goto cleanup;
+}
+Py_INCREF(pyobj_cbData);
+
+/* Call the Callback Dispatcher */
+pyobj_ret = PyObject_CallMethod(pyobj_conn,
+
(char*)"_dispatchDomainEventBlockThresholdCallback",
+(char*)"OssiiO",
+pyobj_dom, dev, path, threshold, excess,
+pyobj_cbData);
+
+Py_DECREF(pyobj_cbData);
+Py_DECREF(pyobj_dom);
+
+ cleanup:
+if (!pyobj_ret) {
+DEBUG("%s - ret:%p\n", __FUNCTION__, pyobj_ret);
+PyErr_Print();
+} else {
+Py_DECREF(pyobj_ret);
+ret = 0;
+}
+
+LIBVIRT_RELEASE_THREAD_STATE;
+return ret;
+}
+#endif /* VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD */
+
+
 static PyObject *
 libvirt_virConnectDomainEventRegisterAny(PyObject *self ATTRIBUTE_UNUSED,
  PyObject *args)
@@ -7052,6 +7109,11 @@

Re: [libvirt] [PATCH] qemu: domain: Properly lookup top of chain in qemuDomainGetStorageSourceByDevstr

2017-03-29 Thread Peter Krempa

On Wed, Mar 29, 2017 at 10:01:14 -0500, Eric Blake wrote:
> On 03/29/2017 09:58 AM, Peter Krempa wrote:
> > When idx is 0 virStorageFileChainLookup returns the base (bottom) of the
> > backing chain rather than the top. This is expected by the callers of
> > qemuDomainGetStorageSourceByDevstr.
> > 
> > Add a special case for idx == 0
> > ---
> > With this you are not able to specify the top image of a disk when using
> > virDomainSetBlockThreshold in qemu.
> > 
> >  src/qemu/qemu_domain.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> ACK

Pushed; thanks for the quick review!

Peter


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: domain: Properly lookup top of chain in qemuDomainGetStorageSourceByDevstr

2017-03-29 Thread Peter Krempa

When idx is 0 virStorageFileChainLookup returns the base (bottom) of the
backing chain rather than the top. This is expected by the callers of
qemuDomainGetStorageSourceByDevstr.

Add a special case for idx == 0
---
With this you are not able to specify the top image of a disk when using
virDomainSetBlockThreshold in qemu.

 src/qemu/qemu_domain.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 458bb5f9a..589eb1889 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -8605,7 +8605,10 @@ qemuDomainGetStorageSourceByDevstr(const char *devstr,
 goto cleanup;
 }

-src = virStorageFileChainLookup(disk->src, NULL, NULL, idx, NULL);
+if (idx == 0)
+src = disk->src;
+else
+src = virStorageFileChainLookup(disk->src, NULL, NULL, idx, NULL);

  cleanup:
 VIR_FREE(target);
-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/3] qemu: Check migratable host CPU features

2017-03-29 Thread Jiri Denemark

If calling query-cpu-model-expansion on the 'host'/'max' CPU model with
'migratable' property set to false succeeds, we know QEMU is able to
tell us which features would disable migration. Thus we can mark all
enabled features as migratable.

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_capabilities.c   |  53 +-
 src/qemu/qemu_monitor.c|   7 +-
 src/qemu/qemu_monitor.h|   1 +
 src/qemu/qemu_monitor_json.c   |  11 +
 src/qemu/qemu_monitor_json.h   |   3 +-
 tests/cputest.c|   2 +-
 .../qemucapabilitiesdata/caps_2.8.0.s390x.replies  |   8 +
 .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 840 +
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml   | 366 -
 9 files changed, 1103 insertions(+), 188 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 446c15f92..9726bce74 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2807,8 +2807,11 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
bool tcg)
 {
 qemuMonitorCPUModelInfoPtr *modelInfo;
+qemuMonitorCPUModelInfoPtr nonMigratable = NULL;
+virHashTablePtr hash = NULL;
 const char *model;
 qemuMonitorCPUModelExpansionType type;
+int ret = -1;
 
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
 return 0;
@@ -2831,7 +2834,55 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
 else
 type = QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC;
 
-return qemuMonitorGetCPUModelExpansion(mon, type, model, modelInfo);
+if (qemuMonitorGetCPUModelExpansion(mon, type, model, true, modelInfo) < 0)
+return -1;
+
+/* Try to check migratability of each feature. */
+if (*modelInfo &&
+qemuMonitorGetCPUModelExpansion(mon, type, model, false,
+&nonMigratable) < 0)
+goto error;
+
+if (nonMigratable) {
+qemuMonitorCPUPropertyPtr prop;
+qemuMonitorCPUPropertyPtr nmProp;
+size_t i;
+
+if (!(hash = virHashCreate(0, NULL)))
+goto error;
+
+for (i = 0; i < (*modelInfo)->nprops; i++) {
+prop = (*modelInfo)->props + i;
+if (virHashAddEntry(hash, prop->name, prop) < 0)
+goto error;
+}
+
+for (i = 0; i < nonMigratable->nprops; i++) {
+nmProp = nonMigratable->props + i;
+if (!(prop = virHashLookup(hash, nmProp->name)) ||
+prop->type != QEMU_MONITOR_CPU_PROPERTY_BOOLEAN ||
+prop->type != nmProp->type)
+continue;
+
+if (prop->value.boolean)
+prop->migratable = VIR_TRISTATE_BOOL_YES;
+}
+
+(*modelInfo)->migratability = true;
+}
+
+ret = 0;
+
+ cleanup:
+virHashFree(hash);
+qemuMonitorCPUModelInfoFree(nonMigratable);
+
+return ret;
+
+ error:
+qemuMonitorCPUModelInfoFree(*modelInfo);
+*modelInfo = NULL;
+goto cleanup;
 }
 
 struct tpmTypeToCaps {
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index e9ba5fdea..a4fa6eca6 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -3702,13 +3702,16 @@ int
 qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
 qemuMonitorCPUModelExpansionType type,
 const char *model_name,
+bool migratable,
 qemuMonitorCPUModelInfoPtr *model_info)
 {
-VIR_DEBUG("type=%d model_name=%s", type, model_name);
+VIR_DEBUG("type=%d model_name=%s migratable=%d",
+  type, model_name, migratable);
 
 QEMU_CHECK_MONITOR_JSON(mon);
 
-return qemuMonitorJSONGetCPUModelExpansion(mon, type, model_name, 
model_info);
+return qemuMonitorJSONGetCPUModelExpansion(mon, type, model_name,
+   migratable, model_info);
 }
 
 
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 332652178..91ab9057e 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -1014,6 +1014,7 @@ typedef enum {
 int qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
 qemuMonitorCPUModelExpansionType type,
 const char *model_name,
+bool migratable,
 qemuMonitorCPUModelInfoPtr *model_info);
 
 void qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info);
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index b86d4d8e3..aeb777d37 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -5133,10 +5133,12 @@ int
 qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr mon,

[libvirt] [PATCH 0/3 for 3.2.0] Fix host-model CPU with non-migratable features

2017-03-29 Thread Jiri Denemark

This series fixes a regression in libvirt which would break domains with
a CPU defined as, for example:


  


Such domains would work just fine with libvirt <= 3.1.0 or QEMU < 2.9.0,
but they would be broken with current libvirt and QEMU >= 2.9.0.

This is because we started asking QEMU for CPU features supported by the
host CPU, by which we think all non-migratable features are not
supported because QEMU filters them out by default.

This series changes our code to properly detect even non-migratable
features, but still leaves the piece which relies on our cpu_map.xml to
filter them when someone asks for just . Patches
which will use the data provided by QEMU instead of our static database
in cpu_map.xml will be sent soon, since they are not required to fix the
regression.

Jiri Denemark (3):
  qemuMonitorCPUModelInfo: Add support for non-migratable features
  qemu: Check migratable host CPU features
  qemu: Check non-migratable host CPU features

 src/qemu/qemu_capabilities.c   |  96 ++-
 src/qemu/qemu_monitor.c|   9 +-
 src/qemu/qemu_monitor.h|   3 +
 src/qemu/qemu_monitor_json.c   |  11 +
 src/qemu/qemu_monitor_json.h   |   3 +-
 tests/cputest.c|   2 +-
 tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml   |   1 +
 .../qemucapabilitiesdata/caps_2.8.0.s390x.replies  |   8 +
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 840 +
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml   | 368 -
 11 files changed, 1148 insertions(+), 195 deletions(-)

-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 3/3] qemu: Check non-migratable host CPU features

2017-03-29 Thread Jiri Denemark

CPU features which change their value from disabled to enabled between
two calls to query-cpu-model-expansion (the first with no extra
properties set and the second with 'migratable' property set to false)
can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo.

Since the code consuming qemuMonitorCPUModelInfo currently ignores the
migratable flag, this change is effectively changing the CPU model
advertised in domain capabilities to contain all features (even those
which block migration). And this matches what we do for QEMU older than
2.9.0, when we detect all CPUID bits ourselves without asking QEMU.

As a result of this change


  


will work with all QEMU versions. Such CPU definition would be forbidden
with QEMU >= 2.9.0 without this patch.

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_capabilities.c | 6 +-
 tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml | 1 +
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 9726bce74..b1245ad5d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2864,8 +2864,12 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
 prop->type != nmProp->type)
 continue;
 
-if (prop->value.boolean)
+if (prop->value.boolean) {
 prop->migratable = VIR_TRISTATE_BOOL_YES;
+} else if (nmProp->value.boolean) {
+prop->value.boolean = true;
+prop->migratable = VIR_TRISTATE_BOOL_NO;
+}
 }
 
 (*modelInfo)->migratability = true;
diff --git a/tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml 
b/tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml
index a4ab74dca..e8fe01d85 100644
--- a/tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml
+++ b/tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml
@@ -30,6 +30,7 @@
   
   
   
+  
 
 
   qemu64
diff --git a/tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml 
b/tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml
index 6efa8a668..6386c4ed0 100644
--- a/tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml
@@ -314,7 +314,7 @@
 
 
 
-
+
 
 
 
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] tests: Rename VIRT_TEST_* macros to VIR_TEST_*

2017-03-29 Thread Andrea Bolognani

We use the "vir" prefix pretty consistently in our
APIs, both external and internal, which made these
macros stood out.
---
 tests/bhyveargv2xmltest.c  | 2 +-
 tests/bhyvexml2argvtest.c  | 2 +-
 tests/bhyvexml2xmltest.c   | 2 +-
 tests/commandtest.c| 2 +-
 tests/cputest.c| 2 +-
 tests/domaincapstest.c | 4 ++--
 tests/domainconftest.c | 2 +-
 tests/domainsnapshotxml2xmltest.c  | 2 +-
 tests/esxutilstest.c   | 2 +-
 tests/eventtest.c  | 2 +-
 tests/fchosttest.c | 2 +-
 tests/fdstreamtest.c   | 2 +-
 tests/genericxml2xmltest.c | 2 +-
 tests/interfacexml2xmltest.c   | 2 +-
 tests/jsontest.c   | 2 +-
 tests/lxcconf2xmltest.c| 2 +-
 tests/lxcxml2xmltest.c | 2 +-
 tests/metadatatest.c   | 2 +-
 tests/networkxml2conftest.c| 2 +-
 tests/networkxml2firewalltest.c| 2 +-
 tests/networkxml2xmltest.c | 2 +-
 tests/networkxml2xmlupdatetest.c   | 2 +-
 tests/nodedevxml2xmltest.c | 2 +-
 tests/nsstest.c| 2 +-
 tests/nwfilterebiptablestest.c | 2 +-
 tests/nwfilterxml2firewalltest.c   | 2 +-
 tests/nwfilterxml2xmltest.c| 2 +-
 tests/objecteventtest.c| 2 +-
 tests/openvzutilstest.c| 2 +-
 tests/qemuagenttest.c  | 2 +-
 tests/qemuargv2xmltest.c   | 2 +-
 tests/qemucapabilitiestest.c   | 2 +-
 tests/qemucaps2xmltest.c   | 2 +-
 tests/qemucapsprobe.c  | 2 +-
 tests/qemucommandutiltest.c| 2 +-
 tests/qemuhelptest.c   | 2 +-
 tests/qemuhotplugtest.c| 2 +-
 tests/qemumemlocktest.c| 2 +-
 tests/qemumonitorjsontest.c| 2 +-
 tests/qemumonitortest.c| 2 +-
 tests/qemuxml2argvtest.c   | 2 +-
 tests/qemuxml2xmltest.c| 2 +-
 tests/scsihosttest.c   | 2 +-
 tests/seclabeltest.c   | 2 +-
 tests/secretxml2xmltest.c  | 2 +-
 tests/securityselinuxlabeltest.c   | 2 +-
 tests/securityselinuxtest.c| 2 +-
 tests/sexpr2xmltest.c  | 2 +-
 tests/sockettest.c | 2 +-
 tests/storagebackendsheepdogtest.c | 2 +-
 tests/storagepoolxml2xmltest.c | 2 +-
 tests/storagevolxml2argvtest.c | 2 +-
 tests/storagevolxml2xmltest.c  | 2 +-
 tests/sysinfotest.c| 2 +-
 tests/testutils.c  | 4 ++--
 tests/testutils.h  | 6 +++---
 tests/utiltest.c   | 2 +-
 tests/vboxsnapshotxmltest.c| 2 +-
 tests/viralloctest.c   | 2 +-
 tests/viratomictest.c  | 2 +-
 tests/virauthconfigtest.c  | 2 +-
 tests/virbitmaptest.c  | 2 +-
 tests/virbuftest.c | 2 +-
 tests/vircaps2xmltest.c| 2 +-
 tests/vircapstest.c| 2 +-
 tests/vircgrouptest.c  | 2 +-
 tests/virconftest.c| 2 +-
 tests/vircryptotest.c  | 2 +-
 tests/virdbustest.c| 2 +-
 tests/virdrivermoduletest.c| 2 +-
 tests/virendiantest.c  | 2 +-
 tests/virfiletest.c| 2 +-
 tests/virfirewalltest.c| 4 ++--
 tests/virhashtest.c| 2 +-
 tests/virhostcputest.c | 2 +-
 tests/virhostdevtest.c | 2 +-
 tests/viridentitytest.c| 4 ++--
 tests/viriscsitest.c   | 2 +-
 tests/virkeycodetest.c | 2 +-
 tests/virkeyfiletest.c | 2 +-
 tests/virkmodtest.c| 2 +-
 tests/virlockspacetest.c   | 2 +-
 tests/virlogtest.c | 2 +-
 tests/virmacmaptest.c  | 2 +-
 tests/virnetdaemontest.c   | 4 ++--
 tests/virnetdevbandwidthtest.c | 2 +-
 tests/virnetdevtest.c  | 2 +-
 tests/virnetmessagetest.c  | 2 +-
 tests/virnetserverclienttest.c | 4 ++--
 tests/virnetsockettest.c   | 2 +-
 tests/virnettlscontexttest.c   | 2 +-
 tests/virnettlssessiontest.c   | 2 +-
 tests/virpcitest.c | 2 +-
 tests/virpolkittest.c  | 2 +-
 tests/virportallocatortest.c   | 2 +-
 tests/virrotatingfiletest.c| 2 +-
 tests/virschematest.c  | 2 +-
 tests/virscsitest.c| 2 +-
 tests/virshtest.c  | 2 +-
 tests/virstoragetest.c | 2 +-
 tests/virstringtest.c  | 2 +-
 tests/virsystemdtest.c | 2 +-
 tests/virtimetest.c| 2 +-
 tests/virtypedparamtest.c  | 2 +-
 tests/viruritest.c | 2 +-
 tests/virusbtest.c | 2 +-
 tests/vmwarevertest.c  | 2 +-
 tests/vmx2xmltest.c| 2 +-
 tests/xencapstest.c| 2 +-
 tests/xlconfigtest.c   | 2 +-
 tests/xmconfigtest.c   | 2 +-
 tests/xml2sexprtest.c  | 2 +-
 tests/xml2vmxtest.c| 2 +-

Re: [libvirt] [PATCH v2 4/4] news: Add template for a section

2017-03-29 Thread Ján Tomko


On Wed, Mar 29, 2017 at 09:28:16AM +0200, Peter Krempa wrote:

After the release it's necessary to add a new  section for the
upcoming release. Add a template so that it does not have to be
compiled over and over again.


s/compiled/copied/?

Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 0/4] Add schema validation for news

2017-03-29 Thread Ján Tomko


On Wed, Mar 29, 2017 at 09:28:12AM +0200, Peter Krempa wrote:

v2:
- rename DO_TEST to DO_TEST_DIR along with changes in the first patch
- add 'abs_srcdir' to the tested XML path so that vpath builds work
- fix wording of the rules for adding news entries
- fix commit messages

Peter Krempa (4):
 tests: schema: Add possibility to validate individual files
 news: Introduce rules for the schema file and fix offending lines
 schema: Introduce schema for the news.xml file
 news: Add template for a  section

docs/news.xml | 62 -
docs/schemas/news.rng | 73 
tests/virschematest.c | 77 ---
3 files changed, 171 insertions(+), 41 deletions(-)
create mode 100644 docs/schemas/news.rng


ACK series

Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 1/5] qemu: Split virQEMUCapsInitArchQMPBasic()

2017-03-29 Thread Andrea Bolognani

Instead of having a single function that probes the
architecture from the monitor and then sets a bunch of
basic capabilities based on it, have a separate function
for each part: virQEMUCapsInitQMPArch() only sets the
architecture, and virQEMUCapsInitQMPBasicArch() only sets
the capabilities.

This split will be useful later on, when we will want to
set basic capabilities from the test suite without having
to go through the pain of mocking the monitor.
---
This is 99% pure code motion; however, an early 'return -1'
has been converted to the equivalent 'goto cleanup'.

 src/qemu/qemu_capabilities.c | 42 +++---
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index f51141b..eec2ee4 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4177,18 +4177,25 @@ virQEMUCapsInitQMPBasic(virQEMUCapsPtr qemuCaps)
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_DISPLAY);
 }
 
-/* Capabilities that are architecture depending
- * initialized for QEMU.
+
+/**
+ * virQEMUCapsInitQMPArch:
+ * @qemuCaps: QEMU capabilities
+ * @mon: QEMU monitor
+ *
+ * Initialize the architecture for @qemuCaps by asking @mon.
+ *
+ * Returns: 0 on success, <0 on failure
  */
 static int
-virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
+virQEMUCapsInitQMPArch(virQEMUCapsPtr qemuCaps,
 qemuMonitorPtr mon)
 {
 char *archstr = NULL;
 int ret = -1;
 
 if (!(archstr = qemuMonitorGetTargetArch(mon)))
-return -1;
+goto cleanup;
 
 if ((qemuCaps->arch = virQEMUCapsArchFromString(archstr)) == 
VIR_ARCH_NONE) {
 virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -4196,18 +4203,29 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
 goto cleanup;
 }
 
+ret = 0;
+
+ cleanup:
+VIR_FREE(archstr);
+return ret;
+}
+
+
+/**
+ * virQEMUCapsInitQMPBasicArch:
+ * @qemuCaps: QEMU capabilities
+ *
+ * Initialize @qemuCaps with basic architecture-dependent capabilities.
+ */
+static void
+virQEMUCapsInitQMPBasicArch(virQEMUCapsPtr qemuCaps)
+{
 /* ACPI/HPET/KVM PIT are x86 specific */
 if (ARCH_IS_X86(qemuCaps->arch)) {
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_HPET);
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
 }
-
-ret = 0;
-
- cleanup:
-VIR_FREE(archstr);
-return ret;
 }
 
 
@@ -4432,9 +4450,11 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
 
 virQEMUCapsInitQMPBasic(qemuCaps);
 
-if (virQEMUCapsInitArchQMPBasic(qemuCaps, mon) < 0)
+if (virQEMUCapsInitQMPArch(qemuCaps, mon) < 0)
 goto cleanup;
 
+virQEMUCapsInitQMPBasicArch(qemuCaps);
+
 /* USB option is supported v1.3.0 onwards */
 if (qemuCaps->version >= 1003000)
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_USB_OPT);
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 0/5] qemu: ACPI and UEFI fixes

2017-03-29 Thread Andrea Bolognani

Changes from [v1]:

  * use a dedicated function for setting basic arch-dependent
capabilities instead of having two copies of the same
code that will have to be kept in sync;

  * enforce requirements at guest validation time rather than
at command line creation time;

  * shuffle patches around so that the order has more sense;

  * make test files slightly smaller and nicer.


[v1] https://www.redhat.com/archives/libvir-list/2017-March/msg00429.html

Andrea Bolognani (5):
  qemu: Split virQEMUCapsInitArchQMPBasic()
  tests: Initialize basic capabilities properly
  qemu: Advertise ACPI support for aarch64 guests
  qemu: Enforce ACPI, UEFI requirements
  tests: Test ACPI, UEFI requirements

 src/qemu/qemu_capabilities.c   | 68 --
 src/qemu/qemu_capabilities.h   |  2 +
 src/qemu/qemu_command.c| 20 ++-
 src/qemu/qemu_domain.c | 20 +++
 .../caps_2.6.0-gicv2.aarch64.xml   |  1 +
 .../caps_2.6.0-gicv3.aarch64.xml   |  1 +
 .../qemuxml2argv-aarch64-aavmf-virtio-mmio.args|  1 +
 .../qemuxml2argv-aarch64-aavmf-virtio-mmio.xml |  1 -
 args => qemuxml2argv-aarch64-acpi-nouefi.args} |  9 +--
 .../qemuxml2argv-aarch64-acpi-nouefi.xml   | 22 +++
 .../qemuxml2argv-aarch64-acpi-uefi.args| 22 +++
 .../qemuxml2argv-aarch64-acpi-uefi.xml | 21 +++
 .../qemuxml2argv-aarch64-cpu-passthrough.args  |  1 +
 .../qemuxml2argv-aarch64-cpu-passthrough.xml   |  1 -
 ...rgs => qemuxml2argv-aarch64-noacpi-nouefi.args} | 13 +++--
 .../qemuxml2argv-aarch64-noacpi-nouefi.xml | 19 ++
 .../qemuxml2argv-aarch64-noacpi-uefi.args  | 23 
 .../qemuxml2argv-aarch64-noacpi-uefi.xml   | 18 ++
 .../qemuxml2argv-aarch64-video-virtio-gpu-pci.args |  1 +
 .../qemuxml2argv-aarch64-video-virtio-gpu-pci.xml  |  3 -
 ...l2argv-aarch64-virt-2.6-virtio-pci-default.args |  1 +
 ...ml2argv-aarch64-virt-2.6-virtio-pci-default.xml |  1 -
 .../qemuxml2argv-aarch64-virt-default-nic.args |  1 +
 .../qemuxml2argv-aarch64-virt-default-nic.xml  |  3 -
 .../qemuxml2argv-aarch64-virt-virtio.args  |  1 +
 .../qemuxml2argv-aarch64-virt-virtio.xml   |  1 -
 .../qemuxml2argv-aarch64-virtio-pci-default.args   |  1 +
 .../qemuxml2argv-aarch64-virtio-pci-default.xml|  1 -
 ...l2argv-aarch64-virtio-pci-manual-addresses.args |  1 +
 ...ml2argv-aarch64-virtio-pci-manual-addresses.xml |  1 -
 .../qemuxml2argv-balloon-ccw-deflate.args  |  1 -
 .../qemuxml2argv-balloon-mmio-deflate.args |  1 +
 .../qemuxml2argv-balloon-mmio-deflate.xml  |  1 -
 .../qemuxml2argv-console-sclp.args |  1 -
 .../qemuxml2argv-console-virtio-ccw.args   |  1 -
 .../qemuxml2argv-console-virtio-s390.args  |  1 -
 .../qemuxml2argv-cpu-s390-features.args|  1 -
 .../qemuxml2argv-cpu-s390-zEC12.args   |  1 -
 .../qemuxml2argv-disk-virtio-ccw-many.args |  1 -
 .../qemuxml2argv-disk-virtio-ccw.args  |  1 -
 .../qemuxml2argv-disk-virtio-s390.args |  1 -
 .../qemuxml2argv-disk-virtio-scsi-ccw.args |  1 -
 tests/qemuxml2argvdata/qemuxml2argv-fs9p-ccw.args  |  1 -
 .../qemuxml2argv-hostdev-scsi-vhost-scsi-ccw.args  |  1 -
 .../qemuxml2argv-hugepages-numa.args   |  1 +
 .../qemuxml2argv-iothreads-disk-virtio-ccw.args|  1 -
 .../qemuxml2argv-iothreads-virtio-scsi-ccw.args|  1 -
 .../qemuxml2argv-machine-aeskeywrap-off-cap.args   |  1 -
 .../qemuxml2argv-machine-aeskeywrap-off-caps.args  |  1 -
 .../qemuxml2argv-machine-aeskeywrap-on-cap.args|  1 -
 .../qemuxml2argv-machine-aeskeywrap-on-caps.args   |  1 -
 .../qemuxml2argv-machine-deakeywrap-off-cap.args   |  1 -
 .../qemuxml2argv-machine-deakeywrap-off-caps.args  |  1 -
 .../qemuxml2argv-machine-deakeywrap-on-cap.args|  1 -
 .../qemuxml2argv-machine-deakeywrap-on-caps.args   |  1 -
 .../qemuxml2argv-machine-keywrap-none-caps.args|  1 -
 .../qemuxml2argv-machine-keywrap-none.args |  1 -
 .../qemuxml2argv-memory-hotplug-ppc64-nonuma.args  |  1 -
 .../qemuxml2argv-net-virtio-ccw.args   |  1 -
 .../qemuxml2argv-net-virtio-s390.args  |  1 -
 tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args   |  1 -
 .../qemuxml2argv-ppce500-serial.args   |  1 -
 .../qemuxml2argv-pseries-basic.args|  1 -
 .../qemuxml2argv-pseries-cpu-compat.args   |  1 -
 .../qemuxml2argv-pseries-cpu-exact.args|  1 -
 .../qemuxml2argv-pseries-cpu-le.args   |  1 -
 .../qemuxml2argv-pseries-nvram.args|  1 -
 .../qemuxml2argv-pseries-panic-missing.args|  1 -
 .../qemuxml2argv-pseries-panic-no-address.args |  1 -
 .../qemuxml2argv-pseries-usb-default.args  |  1 -
 .../qemuxml2argv-pseries-usb-kbd.args  |  1 -
 .../qemuxml2argv-pseri

[libvirt] [PATCH v2 3/5] qemu: Advertise ACPI support for aarch64 guests

2017-03-29 Thread Andrea Bolognani

So far, libvirt has assumed that only x86 supports ACPI,
but that's inaccurate since aarch64 supports it too.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
---
 src/qemu/qemu_capabilities.c   | 28 --
 .../caps_2.6.0-gicv2.aarch64.xml   |  1 +
 .../caps_2.6.0-gicv3.aarch64.xml   |  1 +
 .../qemuxml2argv-aarch64-gic-host.args |  1 +
 .../qemuxml2argv-aarch64-gic-v2.args   |  1 +
 .../qemuxml2argv-aarch64-gic-v3.args   |  1 +
 6 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index d9a1f8b..d8ed88b 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1043,13 +1043,17 @@ virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
 
 machines = NULL;
 nmachines = 0;
+}
 
+if ((ARCH_IS_X86(guestarch) || guestarch == VIR_ARCH_AARCH64) &&
+virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL) {
+goto cleanup;
 }
 
 if (ARCH_IS_X86(guestarch) &&
-(virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL ||
- virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL))
+virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL) {
 goto cleanup;
+}
 
 if ((guestarch == VIR_ARCH_I686) &&
 (virCapabilitiesAddGuestFeature(guest, "pae", true, false) == NULL ||
@@ -4096,10 +4100,15 @@ virQEMUCapsInitHelp(virQEMUCapsPtr qemuCaps, uid_t 
runUid, gid_t runGid, const c
 qmperr) < 0)
 goto cleanup;
 
-/* -no-acpi is not supported on non-x86
- * even if qemu reports it in -help */
-if (!ARCH_IS_X86(qemuCaps->arch))
+/* Older QEMU versions reported -no-acpi in the output of -help even
+ * though it was not supported by the architecture. The issue has since
+ * been fixed, but to maintain compatibility with all release we still
+ * need to filter out the capability for architectures that we know
+ * don't support the feature, eg. anything but x86 and aarch64 */
+if (!ARCH_IS_X86(qemuCaps->arch) &&
+qemuCaps->arch != VIR_ARCH_AARCH64) {
 virQEMUCapsClear(qemuCaps, QEMU_CAPS_NO_ACPI);
+}
 
 /* virQEMUCapsExtractDeviceStr will only set additional caps if qemu
  * understands the 0.13.0+ notion of "-device driver,".  */
@@ -4220,9 +4229,14 @@ virQEMUCapsInitQMPArch(virQEMUCapsPtr qemuCaps,
 void
 virQEMUCapsInitQMPBasicArch(virQEMUCapsPtr qemuCaps)
 {
-/* ACPI/HPET/KVM PIT are x86 specific */
-if (ARCH_IS_X86(qemuCaps->arch)) {
+/* ACPI only works on x86 and aarch64 */
+if (ARCH_IS_X86(qemuCaps->arch) ||
+qemuCaps->arch == VIR_ARCH_AARCH64) {
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
+}
+
+/* HPET and KVM PIT are x86 specific */
+if (ARCH_IS_X86(qemuCaps->arch)) {
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_HPET);
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
 }
diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml 
b/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
index c1e4679..af3a8e7 100644
--- a/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
@@ -40,6 +40,7 @@
   
   
   
+  
   
   
   
diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml 
b/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
index 20dfda2..4402ffa 100644
--- a/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
@@ -40,6 +40,7 @@
   
   
   
+  
   
   
   
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.args 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.args
index 5fdaa08..23276ad 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.args
@@ -15,4 +15,5 @@ QEMU_AUDIO_DRV=none \
 -nographic \
 -nodefaults \
 -monitor unix:/tmp/lib/domain--1-aarch64test/monitor.sock,server,nowait \
+-no-acpi \
 -boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v2.args 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v2.args
index 2caf1b9..f79c1c6 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v2.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v2.args
@@ -15,4 +15,5 @@ QEMU_AUDIO_DRV=none \
 -nographic \
 -nodefaults \
 -monitor unix:/tmp/lib/domain--1-aarch64test/monitor.sock,server,nowait \
+-no-acpi \
 -boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args
index 3ae8e5f..fce9308 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args
@@ -15,4 +15,5 @@ QEMU_AUDIO_DRV=none \
 -nographic \
 -no

[libvirt] [PATCH v2 2/5] tests: Initialize basic capabilities properly

2017-03-29 Thread Andrea Bolognani

The capabilities used in test cases should match those used
during normal operation for the tests to make any sense.
---
 src/qemu/qemu_capabilities.c  | 2 +-
 src/qemu/qemu_capabilities.h  | 2 ++
 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v2.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-console-virtio-ccw.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-console-virtio-s390.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw-many.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-s390.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-ccw.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-fs9p-ccw.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi-ccw.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-hugepages-numa.args   | 1 +
 tests/qemuxml2argvdata/qemuxml2argv-iothreads-disk-virtio-ccw.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-iothreads-virtio-scsi-ccw.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-off-cap.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-off-caps.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-on-cap.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-aeskeywrap-on-caps.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-off-cap.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-off-caps.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-on-cap.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-deakeywrap-on-caps.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-keywrap-none-caps.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-machine-keywrap-none.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-ppc64-nonuma.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-ccw.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-s390.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-compat.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-le.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-panic-missing.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-panic-no-address.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-default.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-kbd.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-multi.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args  | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args   | 1 +
 .../qemuxml2argv-s390-allow-bogus-usb-controller.args | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-s390-allow-bogus-usb-none.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-s390-panic-missing.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-s390-panic-no-address.args| 1 -
 tests/qemuxml2argvdata/qemuxml2argv-virtio-rng-ccw.args   | 1 -
 tests/qemuxml2argvdata/qemuxml2argv-watchdog-diag288.args | 1 -
 tests/qemuxml2argvtest.c  | 4 ++--
 55 files changed, 7 insertions(+), 53 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index eec2ee4..d9a1f8b 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4217,7 +4217,7 @@ virQEMUCapsInitQMPArch(virQEMUCapsPtr qemuCaps,
  *
  * Initialize @qemuCaps with basic architecture-dependent capabilities.
  */
-static void
+void
 virQEMUCapsInitQMPBasicArch(virQEMUCapsPtr qemuCaps)
 {
 /* ACPI/HPET/KVM PIT are x86 specific */
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index d44682f..24e2f38 100644
--- a/src/qemu/qemu_capabilities.h

[libvirt] [PATCH v2 4/5] qemu: Enforce ACPI, UEFI requirements

2017-03-29 Thread Andrea Bolognani

Depending on the architecture, requirements for ACPI and UEFI can
be different; more specifically, while on x86 UEFI requires ACPI,
on aarch64 it's the other way around.

Enforce these requirements when validating the domain, and make
the error message more accurate by mentioning that they're not
necessarily applicable to all architectures.

Several aarch64 test cases had to be tweaked because they would
have failed the validation step otherwise.
---
 src/qemu/qemu_command.c  | 20 
 src/qemu/qemu_domain.c   | 20 
 .../qemuxml2argv-aarch64-aavmf-virtio-mmio.args  |  1 +
 .../qemuxml2argv-aarch64-aavmf-virtio-mmio.xml   |  1 -
 .../qemuxml2argv-aarch64-cpu-passthrough.args|  1 +
 .../qemuxml2argv-aarch64-cpu-passthrough.xml |  1 -
 .../qemuxml2argv-aarch64-video-virtio-gpu-pci.args   |  1 +
 .../qemuxml2argv-aarch64-video-virtio-gpu-pci.xml|  3 ---
 ...xml2argv-aarch64-virt-2.6-virtio-pci-default.args |  1 +
 ...uxml2argv-aarch64-virt-2.6-virtio-pci-default.xml |  1 -
 .../qemuxml2argv-aarch64-virt-default-nic.args   |  1 +
 .../qemuxml2argv-aarch64-virt-default-nic.xml|  3 ---
 .../qemuxml2argv-aarch64-virt-virtio.args|  1 +
 .../qemuxml2argv-aarch64-virt-virtio.xml |  1 -
 .../qemuxml2argv-aarch64-virtio-pci-default.args |  1 +
 .../qemuxml2argv-aarch64-virtio-pci-default.xml  |  1 -
 ...xml2argv-aarch64-virtio-pci-manual-addresses.args |  1 +
 ...uxml2argv-aarch64-virtio-pci-manual-addresses.xml |  1 -
 .../qemuxml2argv-balloon-mmio-deflate.args   |  1 +
 .../qemuxml2argv-balloon-mmio-deflate.xml|  1 -
 .../qemuxml2xmlout-aarch64-aavmf-virtio-mmio.xml |  1 -
 .../qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml  |  1 -
 .../qemuxml2xmlout-aarch64-virtio-pci-default.xml|  1 -
 ...ml2xmlout-aarch64-virtio-pci-manual-addresses.xml |  1 -
 24 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 64d2d71..5cf383a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -9324,18 +9324,16 @@ qemuBuildRedirdevCommandLine(virLogManagerPtr 
logManager,
 }
 
 
-static int
+static void
 qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
- virDomainDefPtr def,
- virQEMUCapsPtr qemuCaps)
+ virDomainDefPtr def)
 {
-int ret = -1;
 virDomainLoaderDefPtr loader = def->os.loader;
 virBuffer buf = VIR_BUFFER_INITIALIZER;
 int unit = 0;
 
 if (!loader)
-return 0;
+return;
 
 switch ((virDomainLoader) loader->type) {
 case VIR_DOMAIN_LOADER_TYPE_ROM:
@@ -9344,12 +9342,6 @@ qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
 break;
 
 case VIR_DOMAIN_LOADER_TYPE_PFLASH:
-if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_ACPI) &&
-def->features[VIR_DOMAIN_FEATURE_ACPI] != VIR_TRISTATE_SWITCH_ON) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("ACPI must be enabled in order to use UEFI"));
-goto cleanup;
-}
 
 if (loader->secure == VIR_TRISTATE_BOOL_YES) {
 virCommandAddArgList(cmd,
@@ -9387,10 +9379,7 @@ qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
 break;
 }
 
-ret = 0;
- cleanup:
 virBufferFreeAndReset(&buf);
-return ret;
 }
 
 
@@ -9827,8 +9816,7 @@ qemuBuildCommandLine(virQEMUDriverPtr driver,
 if (qemuBuildCpuCommandLine(cmd, driver, def, qemuCaps) < 0)
 goto error;
 
-if (qemuBuildDomainLoaderCommandLine(cmd, def, qemuCaps) < 0)
-goto error;
+qemuBuildDomainLoaderCommandLine(cmd, def);
 
 if (!migrateURI && !snapshot && qemuDomainAlignMemorySizes(def) < 0)
 goto error;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 458bb5f..e41e8e4 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2884,6 +2884,26 @@ qemuDomainDefValidate(const virDomainDef *def,
 goto cleanup;
 }
 
+/* On x86, UEFI requires ACPI */
+if (def->os.loader &&
+def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH &&
+ARCH_IS_X86(def->os.arch) &&
+def->features[VIR_DOMAIN_FEATURE_ACPI] != VIR_TRISTATE_SWITCH_ON) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("UEFI requires ACPI on this architecture"));
+goto cleanup;
+}
+
+/* On aarch64, ACPI requires UEFI */
+if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON &&
+def->os.arch == VIR_ARCH_AARCH64 &&
+(!def->os.loader ||
+ def->os.loader->type != VIR_DOMAIN_LOADER_TYPE_PFLASH)) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("ACPI requires UEFI on this architecture"));
+return -1;
+}
+
 if (def-

[libvirt] [PATCH v2 5/5] tests: Test ACPI, UEFI requirements

2017-03-29 Thread Andrea Bolognani

Make sure every combination of ACPI and UEFI works, or fails to
work, as expected.
---
 .../qemuxml2argv-aarch64-acpi-nouefi.args  | 22 +
 .../qemuxml2argv-aarch64-acpi-nouefi.xml   | 22 +
 .../qemuxml2argv-aarch64-acpi-uefi.args| 22 +
 .../qemuxml2argv-aarch64-acpi-uefi.xml | 21 
 .../qemuxml2argv-aarch64-noacpi-nouefi.args| 22 +
 .../qemuxml2argv-aarch64-noacpi-nouefi.xml | 19 ++
 .../qemuxml2argv-aarch64-noacpi-uefi.args  | 23 ++
 .../qemuxml2argv-aarch64-noacpi-uefi.xml   | 18 +
 .../qemuxml2argv-q35-acpi-nouefi.args  | 21 
 .../qemuxml2argv-q35-acpi-nouefi.xml   | 22 +
 .../qemuxml2argv-q35-acpi-uefi.args| 22 +
 .../qemuxml2argv-q35-acpi-uefi.xml | 21 
 .../qemuxml2argv-q35-noacpi-nouefi.args| 22 +
 .../qemuxml2argv-q35-noacpi-nouefi.xml | 19 ++
 .../qemuxml2argv-q35-noacpi-uefi.xml   | 18 +
 tests/qemuxml2argvtest.c   | 14 +
 16 files changed, 328 insertions(+)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.xml
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-nouefi.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-nouefi.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-uefi.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-noacpi-uefi.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-nouefi.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-nouefi.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-uefi.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-acpi-uefi.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-noacpi-nouefi.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-noacpi-nouefi.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-noacpi-uefi.xml

diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.args 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.args
new file mode 100644
index 000..5d9e1fb
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.args
@@ -0,0 +1,22 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-aarch64 \
+-name guest \
+-S \
+-M virt \
+-cpu host \
+-m 1024 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid 496d7ea8-9739-544b-4ebd-ef08be936e8b \
+-nographic \
+-nodefconfig \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest/monitor.sock,server,nowait \
+-boot c \
+-kernel /var/lib/libvirt/images/guest.vmlinux \
+-initrd /var/lib/libvirt/images/guest.initramfs \
+-append 'console=ttyAMA0 rw root=/dev/vda rootwait'
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.xml
new file mode 100644
index 000..cda1b1b
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-nouefi.xml
@@ -0,0 +1,22 @@
+
+  guest
+  496d7ea8-9739-544b-4ebd-ef08be936e8b
+  1048576
+  1
+  
+hvm
+/var/lib/libvirt/images/guest.vmlinuz
+/var/lib/libvirt/images/guest.initramfs
+console=ttyAMA0 rw root=/dev/vda rootwait
+  
+  
+
+  
+  
+cortex-a57
+  
+  
+/usr/bin/qemu-system-aarch64
+
+  
+
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.args 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.args
new file mode 100644
index 000..36371ba
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.args
@@ -0,0 +1,22 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-aarch64 \
+-name guest \
+-S \
+-M virt \
+-cpu cortex-a57 \
+-drive file=/usr/share/AAVMF/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,\
+readonly=on \
+-drive file=/var/lib/libvirt/qemu/nvram/guest_VARS.fd,if=pflash,format=raw,\
+unit=1 \
+-m 1024 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid 496d7ea8-9739-544b-4ebd-ef08be936e8b \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest/monitor.sock,server,nowait \
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-acpi-uefi.xml
new file mode 100644
index 000..5de2eb5
--- /dev/null
+++ b/tests/qemuxml2a

Re: [libvirt] [PATCH 3/4] qemu: Enforce ACPI, UEFI requirements

2017-03-29 Thread Andrea Bolognani

On Mon, 2017-03-27 at 08:03 -0400, John Ferlan wrote:
> > @@ -6252,9 +6252,23 @@ qemuBuildPMCommandLine(virCommandPtr cmd,
> >  virCommandAddArg(cmd, "-no-shutdown");
> >  }
> >  
> > +/* Architectures that support ACPI also support -no-acpi as a way
> > + * of turning it off, and vice versa */
> >  if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_ACPI)) {
> > +
> > +/* ACPI is off unless explicitly turned on */
> >  if (def->features[VIR_DOMAIN_FEATURE_ACPI] != 
> >VIR_TRISTATE_SWITCH_ON)
> >  virCommandAddArg(cmd, "-no-acpi");
> > +
> > +/* aarch64 requires UEFI to be in use for ACPI to work */
> > +if (def->features[VIR_DOMAIN_FEATURE_ACPI] == 
> > VIR_TRISTATE_SWITCH_ON &&
> > +def->os.arch == VIR_ARCH_AARCH64 &&
> > +(!def->os.loader ||
> > + def->os.loader->type != VIR_DOMAIN_LOADER_TYPE_PFLASH)) {
> > +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> > +   _("ACPI requires UEFI on this architecture"));
> > +return -1;
> > +}
> 
> Why isn't this check in qemuDomainDefPostParse?
> 
> Avoids errors in command line building which IIRC was something where
> there was an "effort" to avoid in favor of "earlier" checking.

Good point.

I've actually moved both checks to qemuDomainDefValidate()
rather than qemuDomainDefPostParse(), so that we can prevent
users from defining or starting guests that don't follow the
requirements without losing existing guests.

I've just posted [v2], if you feel like taking a look :)


[v2] https://www.redhat.com/archives/libvir-list/2017-March/msg01531.html
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-perl][PATCH 2/3] Add virDomainSetBlockThreshold API

2017-03-29 Thread Michal Privoznik

Signed-off-by: Michal Privoznik 
---
 Changes|  1 +
 Virt.xs| 12 
 lib/Sys/Virt/Domain.pm |  9 +
 3 files changed, 22 insertions(+)

diff --git a/Changes b/Changes
index 4d6136f..3faaf08 100644
--- a/Changes
+++ b/Changes
@@ -12,6 +12,7 @@ Revision history for perl module Sys::Virt
  - Add PERF_PARAM_ALIGNMENT_FAULTS constant
  - Add PERF_PARAM_EMULATION_FAULTS constant
  - Add block threshold event
+ - Add virDomainSetBlockThreshold API
 
 3.1.0 2017-03-03
 
diff --git a/Virt.xs b/Virt.xs
index e0588f0..a05cf4d 100644
--- a/Virt.xs
+++ b/Virt.xs
@@ -6120,6 +6120,18 @@ send_process_signal(dom, pidsv, signum, flags=0)
   if (virDomainSendProcessSignal(dom, pid, signum, flags) < 0)
   _croak_error();
 
+void
+set_block_threshold(dom, dev, thresholdsv, flags=0)
+virDomainPtr dom;
+const char *dev;
+SV *thresholdsv;
+unsigned int flags;
+ PREINIT:
+unsigned long long threshold;
+  PPCODE:
+  threshold = virt_SvIVull(thresholdsv);
+  if (virDomainSetBlockThreshold(dom, dev, threshold, flags) < 0)
+  _croak_error();
 
 void
 destroy(dom_rv, flags=0)
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index b46eca1..a192ad5 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -1924,6 +1924,15 @@ C<$signum> value must be one of the constants listed
 later, not a POSIX or Linux signal value. C<$flags>
 is currently unused and defaults to zero.
 
+=item $dom->set_block_threshold($dev, $threshold, $flags=0);
+
+Set the threshold level for delivering the
+EVENT_ID_BLOCK_THRESHOLD if the device or backing chain element
+described by C<$dev> is written beyond the set C<$threshold>
+level. The threshold level is unset once the event fires. The
+event might not be delivered at all if libvirtd was not running
+at the moment when the threshold was reached.
+
 =back
 
 =head1 CONSTANTS
-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-perl][PATCH 1/3] Add block threshold event

2017-03-29 Thread Michal Privoznik

Signed-off-by: Michal Privoznik 
---
 Changes|  1 +
 Virt.xs| 48 
 lib/Sys/Virt/Domain.pm |  6 ++
 t/030-api-coverage.t   |  1 +
 4 files changed, 56 insertions(+)

diff --git a/Changes b/Changes
index aee699d..4d6136f 100644
--- a/Changes
+++ b/Changes
@@ -11,6 +11,7 @@ Revision history for perl module Sys::Virt
  - Add PERF_PARAM_PAGE_FAULTS_MAJ constant
  - Add PERF_PARAM_ALIGNMENT_FAULTS constant
  - Add PERF_PARAM_EMULATION_FAULTS constant
+ - Add block threshold event
 
 3.1.0 2017-03-03
 
diff --git a/Virt.xs b/Virt.xs
index e80182f..e0588f0 100644
--- a/Virt.xs
+++ b/Virt.xs
@@ -1136,6 +1136,50 @@ _domain_event_metadata_change_callback(virConnectPtr con,
 
 
 static int
+_domain_event_block_threshold_callback(virConnectPtr con,
+   virDomainPtr dom,
+   const char *dev,
+   const char *path,
+   unsigned long long threshold,
+   unsigned long long excess,
+   void *opaque)
+{
+AV *data = opaque;
+SV **self;
+SV **cb;
+SV *domref;
+dSP;
+
+self = av_fetch(data, 0, 0);
+cb = av_fetch(data, 1, 0);
+
+SvREFCNT_inc(*self);
+
+ENTER;
+SAVETMPS;
+
+PUSHMARK(SP);
+XPUSHs(*self);
+domref = sv_newmortal();
+sv_setref_pv(domref, "Sys::Virt::Domain", (void *) dom);
+virDomainRef(dom);
+XPUSHs(domref);
+XPUSHs(sv_2mortal(newSVpv(dev, 0)));
+XPUSHs(sv_2mortal(newSVpv(path, 0)));
+XPUSHs(sv_2mortal(newSViv(threshold)));
+XPUSHs(sv_2mortal(newSViv(excess)));
+PUTBACK;
+
+call_sv(*cb, G_DISCARD);
+
+FREETMPS;
+LEAVE;
+
+return 0;
+}
+
+
+static int
 _network_event_lifecycle_callback(virConnectPtr con,
  virNetworkPtr net,
  int event,
@@ -3375,6 +3419,9 @@ PREINIT:
   case VIR_DOMAIN_EVENT_ID_METADATA_CHANGE:
   callback = 
VIR_DOMAIN_EVENT_CALLBACK(_domain_event_metadata_change_callback);
   break;
+  case VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD:
+  callback = 
VIR_DOMAIN_EVENT_CALLBACK(_domain_event_block_threshold_callback);
+  break;
   default:
   callback = VIR_DOMAIN_EVENT_CALLBACK(_domain_event_generic_callback);
   break;
@@ -8384,6 +8431,7 @@ BOOT:
   REGISTER_CONSTANT(VIR_DOMAIN_EVENT_ID_JOB_COMPLETED, 
EVENT_ID_JOB_COMPLETED);
   REGISTER_CONSTANT(VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED, 
EVENT_ID_DEVICE_REMOVAL_FAILED);
   REGISTER_CONSTANT(VIR_DOMAIN_EVENT_ID_METADATA_CHANGE, 
EVENT_ID_METADATA_CHANGE);
+  REGISTER_CONSTANT(VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD, 
EVENT_ID_BLOCK_THRESHOLD);
 
   REGISTER_CONSTANT(VIR_DOMAIN_EVENT_WATCHDOG_NONE, EVENT_WATCHDOG_NONE);
   REGISTER_CONSTANT(VIR_DOMAIN_EVENT_WATCHDOG_PAUSE, EVENT_WATCHDOG_PAUSE);
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index eea8b26..b46eca1 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -3274,6 +3274,12 @@ Guest device removal has failed.
 
 The domain metadata has changed
 
+=item Sys::Virt::Domain::EVENT_ID_BLOCK_THRESHOLD
+
+The event occurs when the hypervisor detects that the given
+storage element was written beyond the point specified by
+threshold. The event is useful for thin-provisioned storage.
+
 =back
 
 =head2 IO ERROR EVENT CONSTANTS
diff --git a/t/030-api-coverage.t b/t/030-api-coverage.t
index 3a0d0c5..3049713 100644
--- a/t/030-api-coverage.t
+++ b/t/030-api-coverage.t
@@ -95,6 +95,7 @@ virConnectDomainEventMigrationIterationCallback
 virConnectDomainEventJobCompletedCallback
 virConnectDomainEventDeviceRemovalFailedCallback
 virConnectDomainEventMetadataChangeCallback
+virConnectDomainEventBlockThresholdCallback
 
 virConnectNetworkEventLifecycleCallback
 
-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH 03/11] conf: nodedev: Split virNodeDeviceDefFormat into more functions

2017-03-29 Thread Erik Skultety

On Wed, Mar 29, 2017 at 03:51:54PM +0200, Peter Krempa wrote:
> On Wed, Mar 29, 2017 at 14:51:13 +0200, Erik Skultety wrote:
> > Make the code look cleaner by moving the capability specific bits into
> > separate functions.
> >
> > Signed-off-by: Erik Skultety 
> > ---
> >  src/conf/node_device_conf.c | 578 
> > 
> >  1 file changed, 322 insertions(+), 256 deletions(-)
> >
> > diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
> > index 7d0baa9d1a..72fb9a5611 100644
> > --- a/src/conf/node_device_conf.c
> > +++ b/src/conf/node_device_conf.c
> > @@ -155,6 +155,320 @@ virPCIEDeviceInfoFormat(virBufferPtr buf,
> >  }
> >
> >
> > +static void
> > +virNodeDeviceCapSystemDefFormat(virBufferPtr buf,
> > +const virNodeDevCapData *data)
> > +{
> > +char uuidstr[VIR_UUID_STRING_BUFLEN];
> > +
> > +if (data->system.product_name)
> > +virBufferEscapeString(buf, "%s\n",
> > +  data->system.product_name);
> > +virBufferAddLit(buf, "\n");
> > +virBufferAdjustIndent(buf, 2);
> > +if (data->system.hardware.vendor_name)
> > +virBufferEscapeString(buf, "%s\n",
> > +  data->system.hardware.vendor_name);
> > +if (data->system.hardware.version)
> > +virBufferEscapeString(buf, "%s\n",
> > +  data->system.hardware.version);
>
> virBufferEscapeString automatically skips formatting of the whole string
> if the argument is NULL. So the condition is not necessary.

Again, you're right, but in this case, I was merely moving bits to separate
functions without reviewing the code. Also, it's a fair amount of occurrences,
so for the sake of the future reviewer, aka non-shredder :D, I will adjust this
in a separate patch.

Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-perl][PATCH 0/3] Reflect upstream changes

2017-03-29 Thread Michal Privoznik

Couple of new APIs and constants were added to libvirt.
Reflect them in the perl bindings.

Michal Privoznik (3):
  Add block threshold event
  Add virDomainSetBlockThreshold API
  Add VIR_MIGRATE_TLS constant

 Changes|  3 +++
 Virt.xs| 61 ++
 lib/Sys/Virt/Domain.pm | 22 ++
 t/030-api-coverage.t   |  1 +
 4 files changed, 87 insertions(+)

-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH 03/11] conf: nodedev: Split virNodeDeviceDefFormat into more functions

2017-03-29 Thread Peter Krempa

On Wed, Mar 29, 2017 at 14:51:13 +0200, Erik Skultety wrote:
> Make the code look cleaner by moving the capability specific bits into
> separate functions.
> 
> Signed-off-by: Erik Skultety 
> ---
>  src/conf/node_device_conf.c | 578 
> 
>  1 file changed, 322 insertions(+), 256 deletions(-)
> 
> diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
> index 7d0baa9d1a..72fb9a5611 100644
> --- a/src/conf/node_device_conf.c
> +++ b/src/conf/node_device_conf.c
> @@ -155,6 +155,320 @@ virPCIEDeviceInfoFormat(virBufferPtr buf,
>  }
>  
>  
> +static void
> +virNodeDeviceCapSystemDefFormat(virBufferPtr buf,
> +const virNodeDevCapData *data)
> +{
> +char uuidstr[VIR_UUID_STRING_BUFLEN];
> +
> +if (data->system.product_name)
> +virBufferEscapeString(buf, "%s\n",
> +  data->system.product_name);
> +virBufferAddLit(buf, "\n");
> +virBufferAdjustIndent(buf, 2);
> +if (data->system.hardware.vendor_name)
> +virBufferEscapeString(buf, "%s\n",
> +  data->system.hardware.vendor_name);
> +if (data->system.hardware.version)
> +virBufferEscapeString(buf, "%s\n",
> +  data->system.hardware.version);

virBufferEscapeString automatically skips formatting of the whole string
if the argument is NULL. So the condition is not necessary.


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH 01/11] nodedev: Fix guideline violations in nodedev modules

2017-03-29 Thread Erik Skultety

On Wed, Mar 29, 2017 at 03:50:28PM +0200, Peter Krempa wrote:
> On Wed, Mar 29, 2017 at 14:51:11 +0200, Erik Skultety wrote:
> > We recently started to enforce certain guideline rule a bit more, e.g.
> > functions delimited by 2 newlines in *.c, by 1 newline in *.h, return
> > types on a separate line, etc. This patch adjusts these issues in all
> > nodedev modules.
> >
> > Signed-off-by: Erik Skultety 
> > ---
> >  src/node_device/node_device_driver.c  |  29 +++-
> >  src/node_device/node_device_driver.h  |  82 +++
> >  src/node_device/node_device_hal.c |   9 ++
> >  src/node_device/node_device_linux_sysfs.c |   1 +
> >  src/node_device/node_device_linux_sysfs.h |   9 +-
> >  src/node_device/node_device_udev.c| 233 
> > ++
> >  6 files changed, 238 insertions(+), 125 deletions(-)
> >
> > diff --git a/src/node_device/node_device_driver.c 
> > b/src/node_device/node_device_driver.c
> > index 99f7bc5476..9b1c5bb5e9 100644
> > --- a/src/node_device/node_device_driver.c
> > +++ b/src/node_device/node_device_driver.c
> > @@ -47,7 +47,8 @@
> >
> >  virNodeDeviceDriverStatePtr driver;
> >
> > -static int update_caps(virNodeDeviceObjPtr dev)
> > +static int
> > +update_caps(virNodeDeviceObjPtr dev)
>
> This does not really adhere to the guidelines. Guidelines say that
> functions have to start with 'vir' prefix and use camel case. Also they
> have to contain the name of the module.

Ehmyou just shredded me here to DIN P-6 [1] at least :D, but yeah, you're
absolutely right.

Erik

[1] https://en.wikipedia.org/wiki/Paper_shredder

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-perl][PATCH 3/3] Add VIR_MIGRATE_TLS constant

2017-03-29 Thread Michal Privoznik

Signed-off-by: Michal Privoznik 
---
 Changes| 1 +
 Virt.xs| 1 +
 lib/Sys/Virt/Domain.pm | 7 +++
 3 files changed, 9 insertions(+)

diff --git a/Changes b/Changes
index 3faaf08..f28523a 100644
--- a/Changes
+++ b/Changes
@@ -13,6 +13,7 @@ Revision history for perl module Sys::Virt
  - Add PERF_PARAM_EMULATION_FAULTS constant
  - Add block threshold event
  - Add virDomainSetBlockThreshold API
+ - Add VIR_MIGRATE_TLS constant
 
 3.1.0 2017-03-03
 
diff --git a/Virt.xs b/Virt.xs
index a05cf4d..039f62d 100644
--- a/Virt.xs
+++ b/Virt.xs
@@ -8219,6 +8219,7 @@ BOOT:
   REGISTER_CONSTANT(VIR_MIGRATE_AUTO_CONVERGE, MIGRATE_AUTO_CONVERGE);
   REGISTER_CONSTANT(VIR_MIGRATE_RDMA_PIN_ALL, MIGRATE_RDMA_PIN_ALL);
   REGISTER_CONSTANT(VIR_MIGRATE_POSTCOPY, MIGRATE_POSTCOPY);
+  REGISTER_CONSTANT(VIR_MIGRATE_TLS, MIGRATE_TLS);
 
   REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_BANDWIDTH, 
MIGRATE_PARAM_BANDWIDTH);
   REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_DEST_NAME, 
MIGRATE_PARAM_DEST_NAME);
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index a192ad5..d69bb8d 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -2393,6 +2393,13 @@ Pin memory for RDMA transfer
 
 Enable support for post-copy migration
 
+=item Sys::Virt::Domain::MIGRATE_TLS
+
+Setting this flag will cause the migration to attempt to use the
+TLS environment configured by the hypervisor in order to perform
+the migration. If incorrectly configured on either source or
+destination, the migration will fail.
+
 =back
 
 =head2 UNDEFINE CONSTANTS
-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH 01/11] nodedev: Fix guideline violations in nodedev modules

2017-03-29 Thread Peter Krempa

On Wed, Mar 29, 2017 at 14:51:11 +0200, Erik Skultety wrote:
> We recently started to enforce certain guideline rule a bit more, e.g.
> functions delimited by 2 newlines in *.c, by 1 newline in *.h, return
> types on a separate line, etc. This patch adjusts these issues in all
> nodedev modules.
> 
> Signed-off-by: Erik Skultety 
> ---
>  src/node_device/node_device_driver.c  |  29 +++-
>  src/node_device/node_device_driver.h  |  82 +++
>  src/node_device/node_device_hal.c |   9 ++
>  src/node_device/node_device_linux_sysfs.c |   1 +
>  src/node_device/node_device_linux_sysfs.h |   9 +-
>  src/node_device/node_device_udev.c| 233 
> ++
>  6 files changed, 238 insertions(+), 125 deletions(-)
> 
> diff --git a/src/node_device/node_device_driver.c 
> b/src/node_device/node_device_driver.c
> index 99f7bc5476..9b1c5bb5e9 100644
> --- a/src/node_device/node_device_driver.c
> +++ b/src/node_device/node_device_driver.c
> @@ -47,7 +47,8 @@
>  
>  virNodeDeviceDriverStatePtr driver;
>  
> -static int update_caps(virNodeDeviceObjPtr dev)
> +static int
> +update_caps(virNodeDeviceObjPtr dev)

This does not really adhere to the guidelines. Guidelines say that
functions have to start with 'vir' prefix and use camel case. Also they
have to contain the name of the module.


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 3/3] storage: Fix XPath for looking up gluster volume name

2017-03-29 Thread Peter Krempa

Use the relative lookup specifier rather than the global one. Otherwise
only the first name would be looked up. Add a test case to cover the
scenario.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436574
---
 src/storage/storage_util.c |  2 +-
 .../gluster-parse-multivol-dst.xml | 14 ++
 .../gluster-parse-multivol-src.xml | 32 ++
 tests/virstorageutiltest.c |  1 +
 4 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 tests/virstorageutildata/gluster-parse-multivol-dst.xml
 create mode 100644 tests/virstorageutildata/gluster-parse-multivol-src.xml

diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c
index 8459e9d5b..e949fc3d4 100644
--- a/src/storage/storage_util.c
+++ b/src/storage/storage_util.c
@@ -2862,7 +2862,7 @@ virStorageUtilGlusterExtractPoolSources(const char *host,
 if (!(src = virStoragePoolSourceListNewSource(list)))
 goto cleanup;

-if (!(src->dir = virXPathString("string(//name)", ctxt))) {
+if (!(src->dir = virXPathString("string(./name)", ctxt))) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to extract gluster volume name"));
 goto cleanup;
diff --git a/tests/virstorageutildata/gluster-parse-multivol-dst.xml 
b/tests/virstorageutildata/gluster-parse-multivol-dst.xml
new file mode 100644
index 0..d2d8fefc6
--- /dev/null
+++ b/tests/virstorageutildata/gluster-parse-multivol-dst.xml
@@ -0,0 +1,14 @@
+
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+
diff --git a/tests/virstorageutildata/gluster-parse-multivol-src.xml 
b/tests/virstorageutildata/gluster-parse-multivol-src.xml
new file mode 100644
index 0..0c1f9d10e
--- /dev/null
+++ b/tests/virstorageutildata/gluster-parse-multivol-src.xml
@@ -0,0 +1,32 @@
+
+
+
+  0
+  0
+  
+  
+
+  
+aaa
+d0b219d4-4169-4907-8994-d2e2434854ed
+0
+Created
+0
+  
+  
+test
+32826068-2320-4b62-a825-2554edb7f020
+1
+Started
+0
+  
+  
+test1
+dfa070f4-b12f-4166-8d68-041b73127abc
+0
+Created
+  
+  3
+
+  
+
diff --git a/tests/virstorageutiltest.c b/tests/virstorageutiltest.c
index 0d4ede6c2..90f86233d 100644
--- a/tests/virstorageutiltest.c
+++ b/tests/virstorageutiltest.c
@@ -93,6 +93,7 @@ mymain(void)
 ret = -1

 DO_TEST_GLUSTER_LOOKUP("basic");
+DO_TEST_GLUSTER_LOOKUP("multivol");

 #undef DO_TEST_GLUSTER_LOOKUP

-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 0/3] Fix gluster volume lookup of multiple volumes

2017-03-29 Thread Peter Krempa

Fix the broken XPath and add tests.

Peter Krempa (3):
  storage: util: Split out the gluster volume extraction code into new
function
  test: Introduce testing of virStorageUtilGlusterExtractPoolSources
  storage: Fix XPath for looking up gluster volume name

 src/storage/storage_util.c |  93 +++
 src/storage/storage_util.h |   4 +
 tests/Makefile.am  |  15 ++-
 .../virstorageutildata/gluster-parse-basic-dst.xml |   6 ++
 .../virstorageutildata/gluster-parse-basic-src.xml |  47 ++
 .../gluster-parse-multivol-dst.xml |  14 +++
 .../gluster-parse-multivol-src.xml |  32 +++
 tests/virstorageutiltest.c | 103 +
 8 files changed, 272 insertions(+), 42 deletions(-)
 create mode 100644 tests/virstorageutildata/gluster-parse-basic-dst.xml
 create mode 100644 tests/virstorageutildata/gluster-parse-basic-src.xml
 create mode 100644 tests/virstorageutildata/gluster-parse-multivol-dst.xml
 create mode 100644 tests/virstorageutildata/gluster-parse-multivol-src.xml
 create mode 100644 tests/virstorageutiltest.c

-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/3] test: Introduce testing of virStorageUtilGlusterExtractPoolSources

2017-03-29 Thread Peter Krempa

Add a test program called virstorageutiltest and test the gluster pool
detection code.
---
 tests/Makefile.am  |  15 ++-
 .../virstorageutildata/gluster-parse-basic-dst.xml |   6 ++
 .../virstorageutildata/gluster-parse-basic-src.xml |  47 ++
 tests/virstorageutiltest.c | 102 +
 4 files changed, 167 insertions(+), 3 deletions(-)
 create mode 100644 tests/virstorageutildata/gluster-parse-basic-dst.xml
 create mode 100644 tests/virstorageutildata/gluster-parse-basic-src.xml
 create mode 100644 tests/virstorageutiltest.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index a6f189b8b..254c4c0ad 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -160,7 +160,9 @@ EXTRA_DIST =\
xlconfigdata \
xmconfigdata \
xml2sexprdata \
-   xml2vmxdata
+   xml2vmxdata \
+   virstorageutildata \
+   $(NULL)

 test_helpers = commandhelper ssh
 test_programs = virshtest sockettest \
@@ -352,7 +354,7 @@ test_programs += nwfilterxml2firewalltest
 endif WITH_NWFILTER

 if WITH_STORAGE
-test_programs += storagevolxml2argvtest
+test_programs += storagevolxml2argvtest virstorageutiltest
 endif WITH_STORAGE

 if WITH_STORAGE_FS
@@ -859,6 +861,13 @@ genericxml2xmltest_LDADD = $(LDADDS)


 if WITH_STORAGE
+virstorageutiltest_SOURCES = \
+   virstorageutiltest.c testutils.c testutils.h
+virstorageutiltest_LDADD = \
+   ../src/libvirt_driver_storage_impl.la \
+   $(LDADDS) \
+   $(NULL)
+
 storagevolxml2argvtest_SOURCES = \
 storagevolxml2argvtest.c \
 testutils.c testutils.h
@@ -867,7 +876,7 @@ storagevolxml2argvtest_LDADD = \
../src/libvirt_driver_storage_impl.la $(LDADDS)

 else ! WITH_STORAGE
-EXTRA_DIST += storagevolxml2argvtest.c
+EXTRA_DIST += storagevolxml2argvtest.c virstorageutiltest.c
 endif ! WITH_STORAGE

 storagevolxml2xmltest_SOURCES = \
diff --git a/tests/virstorageutildata/gluster-parse-basic-dst.xml 
b/tests/virstorageutildata/gluster-parse-basic-dst.xml
new file mode 100644
index 0..fbde06f3b
--- /dev/null
+++ b/tests/virstorageutildata/gluster-parse-basic-dst.xml
@@ -0,0 +1,6 @@
+
+  
+
+
+  
+
diff --git a/tests/virstorageutildata/gluster-parse-basic-src.xml 
b/tests/virstorageutildata/gluster-parse-basic-src.xml
new file mode 100644
index 0..08f97cb72
--- /dev/null
+++ b/tests/virstorageutildata/gluster-parse-basic-src.xml
@@ -0,0 +1,47 @@
+
+
+  0
+  0
+  
+  
+
+  
+vol0
+ac14dfa5-0b98-4593-a2aa-9fe2bb9b9ce3
+1
+Started
+0
+2
+2
+1
+2
+0
+0
+0
+2
+Replicate
+0
+
+  virt-gluster-node1:/bricks/brick1/brickvirt-gluster-node1:/bricks/brick1/bricka6f5ddea-bc6a-44db-ae1d-5aa1db7434900
+  virt-gluster-node2:/bricks/brick1/brickvirt-gluster-node2:/bricks/brick1/brickf4ab9fb1-44ec-443b-8783-e5f70ed78da30
+
+3
+
+  
+nfs.disable
+on
+  
+  
+performance.readdir-ahead
+on
+  
+  
+transport.address-family
+inet
+  
+
+  
+  1
+
+  
+
diff --git a/tests/virstorageutiltest.c b/tests/virstorageutiltest.c
new file mode 100644
index 0..0d4ede6c2
--- /dev/null
+++ b/tests/virstorageutiltest.c
@@ -0,0 +1,102 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ */
+
+#include 
+
+#include 
+
+#include "testutils.h"
+#include "virerror.h"
+#include "virfile.h"
+#include "virlog.h"
+#include "virstring.h"
+
+#include "storage/storage_util.h"
+
+#define VIR_FROM_THIS VIR_FROM_NONE
+
+VIR_LOG_INIT("tests.storageutiltest");
+
+
+static int
+testGlusterLookupParse(const void *data)
+{
+virStoragePoolSourceList list = { .type = VIR_STORAGE_POOL_GLUSTER,
+  .nsources = 0,
+  .sources = NULL
+};
+const char *testname = data;
+size_t i;
+char *srcxml = NULL;
+char *srcxmldata = NULL;
+char *destxml = NULL;
+char *actual = NULL;
+int ret = -1;
+
+if (virAsprintf(&srcxml,
+"%s/virstorageutildata/gluster-parse-%s-src.xml",
+

[libvirt] [PATCH 1/3] storage: util: Split out the gluster volume extraction code into new function

2017-03-29 Thread Peter Krempa

To allow testing of the algorithm, split out the extractor into a
separate helper.
---
 src/storage/storage_util.c | 93 +++---
 src/storage/storage_util.h |  4 ++
 2 files changed, 58 insertions(+), 39 deletions(-)

diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c
index 7687eb89a..8459e9d5b 100644
--- a/src/storage/storage_util.c
+++ b/src/storage/storage_util.c
@@ -2836,6 +2836,59 @@ virStorageBackendDeleteLocal(virConnectPtr conn 
ATTRIBUTE_UNUSED,
 }


+int
+virStorageUtilGlusterExtractPoolSources(const char *host,
+const char *xml,
+int pooltype,
+virStoragePoolSourceListPtr list)
+{
+xmlDocPtr doc = NULL;
+xmlXPathContextPtr ctxt = NULL;
+xmlNodePtr *nodes = NULL;
+virStoragePoolSource *src = NULL;
+size_t i;
+int nnodes;
+int ret = -1;
+
+if (!(doc = virXMLParseStringCtxt(xml, _("(gluster_cli_output)"), &ctxt)))
+goto cleanup;
+
+if ((nnodes = virXPathNodeSet("//volumes/volume", ctxt, &nodes)) < 0)
+goto cleanup;
+
+for (i = 0; i < nnodes; i++) {
+ctxt->node = nodes[i];
+
+if (!(src = virStoragePoolSourceListNewSource(list)))
+goto cleanup;
+
+if (!(src->dir = virXPathString("string(//name)", ctxt))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("failed to extract gluster volume name"));
+goto cleanup;
+}
+
+if (VIR_ALLOC_N(src->hosts, 1) < 0)
+goto cleanup;
+src->nhost = 1;
+
+if (VIR_STRDUP(src->hosts[0].name, host) < 0)
+goto cleanup;
+
+src->format = pooltype;
+}
+
+ret = nnodes;
+
+ cleanup:
+VIR_FREE(nodes);
+xmlXPathFreeContext(ctxt);
+xmlFreeDoc(doc);
+
+return ret;
+}
+
+
 /**
  * virStorageBackendFindGlusterPoolSources:
  * @host: host to detect volumes on
@@ -2856,12 +2909,6 @@ virStorageBackendFindGlusterPoolSources(const char *host,
 char *glusterpath = NULL;
 char *outbuf = NULL;
 virCommandPtr cmd = NULL;
-xmlDocPtr doc = NULL;
-xmlXPathContextPtr ctxt = NULL;
-xmlNodePtr *nodes = NULL;
-virStoragePoolSource *src = NULL;
-size_t i;
-int nnodes;
 int rc;

 int ret = -1;
@@ -2892,41 +2939,9 @@ virStorageBackendFindGlusterPoolSources(const char *host,
 goto cleanup;
 }

-if (!(doc = virXMLParseStringCtxt(outbuf, _("(gluster_cli_output)"),
-  &ctxt)))
-goto cleanup;
-
-if ((nnodes = virXPathNodeSet("//volumes/volume", ctxt, &nodes)) < 0)
-goto cleanup;
-
-for (i = 0; i < nnodes; i++) {
-ctxt->node = nodes[i];
-
-if (!(src = virStoragePoolSourceListNewSource(list)))
-goto cleanup;
-
-if (!(src->dir = virXPathString("string(//name)", ctxt))) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("failed to extract gluster volume name"));
-goto cleanup;
-}
-
-if (VIR_ALLOC_N(src->hosts, 1) < 0)
-goto cleanup;
-src->nhost = 1;
-
-if (VIR_STRDUP(src->hosts[0].name, host) < 0)
-goto cleanup;
-
-src->format = pooltype;
-}
-
-ret = nnodes;
+ret = virStorageUtilGlusterExtractPoolSources(host, outbuf, pooltype, 
list);

  cleanup:
-VIR_FREE(nodes);
-xmlXPathFreeContext(ctxt);
-xmlFreeDoc(doc);
 VIR_FREE(outbuf);
 virCommandFree(cmd);
 VIR_FREE(glusterpath);
diff --git a/src/storage/storage_util.h b/src/storage/storage_util.h
index fa3b6522c..bf8424808 100644
--- a/src/storage/storage_util.h
+++ b/src/storage/storage_util.h
@@ -93,6 +93,10 @@ int virStorageBackendDeleteLocal(virConnectPtr conn,
 int virStorageBackendRefreshLocal(virConnectPtr conn,
   virStoragePoolObjPtr pool);

+int virStorageUtilGlusterExtractPoolSources(const char *host,
+const char *xml,
+int pooltype,
+virStoragePoolSourceListPtr list);
 int virStorageBackendFindGlusterPoolSources(const char *host,
 int pooltype,
 virStoragePoolSourceListPtr list,
-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] encountered failed test cases with latest checkout of libvirt

2017-03-29 Thread Eric Blake

On 03/29/2017 04:47 AM, Michal Privoznik wrote:

>>
>> For the valgrind testing with 'make -C tests valgrind', the errors were
>> *mostly* due to
>> "FATAL: can't open suppressions file "./.valgrind.supp". I am using
>> valgrind 3.12.0.

I suspect it may be a simple tweak to makefile to supply an absolute
reference instead of relative to .valgrind.supp so that 'make -C' would
find the right file, for this situation.

> 
> 
> That's weird, the file should be there. What is a problem though is our
> mocking. Due to some weird glibc-ness, valgrind cannot handle libraries
> that have some unresolved symbols. For instance, if library L that is
> loaded from binary B provides symbols L1 and L2 but rely on symbol B1,
> valgrind (in fact glibc) fails to load the binary even though if run
> without valgrind everything works just fine.
> 
> I've looked into this the other day and went from our sources to
> valgrind ones and from there to glibc where I got lost. For instance,
> virpcitest fails because virpcimock uses virAlloc, virFree and other
> internal APIs even though it's not linking with libvirt_util.
> 
> Frankly, I've no idea how to fix this. Perhaps Eric have a bright idea?

Sorry, no bright ideas here.  A strict link ordering (so that no library
relies on unresolved symbols) is a good idea for mingw, so it's worth
shooting for anyways, and may clean up the valgrind issues, but I'm not
sure how easy or hard it would be to rearrange link orders to get to
that point.

> BTW: linking the mock with libvirt_util fails in exactly the opposite
> case - when not running under valgrind.
> 
> Michal
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC PATCH 08/11] nodedev: Introduce udevProcessMediatedDevice

2017-03-29 Thread Erik Skultety

Start discovering the mediated devices on the host system and format the
attributes for the child device into the XML. Compared to the parent
device which reports generic information about the abstract mediated
devices types, a child device only reports the type name it has been
instantiated from and the iommu group number, since that's device
specific compared to the rest of the info that can be gathered about
mdevs at the moment.

The resulting mdev child device XML:

  mdev_4b20d080_1b54_4048_85b3_a6a62d165c01
  /sys/devices/.../4b20d080-1b54-4048-85b3-a6a62d165c01
  pci__06_00_0
  
vfio_mdev
  
  


  


Signed-off-by: Erik Skultety 
---
 src/conf/node_device_conf.c|  6 ++-
 src/node_device/node_device_udev.c | 87 +-
 2 files changed, 71 insertions(+), 22 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 03d7993ab1..1f13484d9b 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -541,9 +541,13 @@ virNodeDeviceDefFormat(const virNodeDeviceDef *def)
 case VIR_NODE_DEV_CAP_DRM:
 virBufferEscapeString(&buf, "%s\n", 
virNodeDevDRMTypeToString(data->drm.type));
 break;
+case VIR_NODE_DEV_CAP_MDEV:
+virBufferEscapeString(&buf, "\n", data->mdev.type);
+virBufferAsprintf(&buf, "\n",
+  data->mdev.iommuGroupNumber);
+break;
 case VIR_NODE_DEV_CAP_FC_HOST:
 case VIR_NODE_DEV_CAP_VPORTS:
-case VIR_NODE_DEV_CAP_MDEV:
 case VIR_NODE_DEV_CAP_LAST:
 break;
 }
diff --git a/src/node_device/node_device_udev.c 
b/src/node_device/node_device_udev.c
index be031fa5a8..092d9456b2 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -324,9 +324,9 @@ udevTranslatePCIIds(unsigned int vendor,
 return 0;
 }
 
-#define MDEV_GET_SYSFS_ATTR(attr, cb, ...)  \
+#define MDEV_GET_SYSFS_ATTR(attr_name, dir, cb, ...)\
 do {\
-if (virAsprintf(&attrpath, "%s/%s", relpath, #attr) < 0)\
+if (virAsprintf(&attrpath, "%s/%s", dir, #attr_name) < 0)   \
 goto cleanup;   \
 \
 if (cb(device, attrpath, __VA_ARGS__) < 0)  \
@@ -345,17 +345,6 @@ udevGetMdevCaps(struct udev_device *device,
 const char *relpath = NULL;   /* diff between @sysfspath and @devpath */
 char *tmp = NULL;
 
-
-/* UDEV doesn't report attributes under subdirectories but can query them
- * if specified as relative paths to the device's base path,
- * e.g. /sys/devices/../:00:01.0/ is the device's base path as udev
- * reports it, but we're interested in attributes under
- * /sys/devices/../:00:01.0/mdev_supported_types//. So, let's
- * strip the common part of the path and let udev chew the relative bit.
- */
-devpath = udev_device_get_syspath(device);
-relpath = sysfspath + strlen(devpath);
-
 /* When calling from the mdev child device, @sysfspath is a symbolic link
  * to the actual mdev type (rather than a physical path), so we need to
  * resolve it in order to get the type's name.
@@ -366,14 +355,24 @@ udevGetMdevCaps(struct udev_device *device,
 if (VIR_STRDUP(mdev->type, last_component(tmp)) < 0)
 goto cleanup;
 
-MDEV_GET_SYSFS_ATTR(name, udevGetStringSysfsAttr,
-&mdev->name);
-MDEV_GET_SYSFS_ATTR(description, udevGetStringSysfsAttr,
-&mdev->description);
-MDEV_GET_SYSFS_ATTR(device_api, udevGetStringSysfsAttr,
-&mdev->device_api);
-MDEV_GET_SYSFS_ATTR(available_instances, udevGetUintSysfsAttr,
-&mdev->available_instances, 10);
+/* UDEV doesn't report attributes under subdirectories by default but is
+ * able to query them if the path to the attribute is relative paths to the
+ * device's base path, e.g. /sys/devices/../:00:01.0/ is the device's
+ * base path as udev reports it, but we're interested in attributes under
+ * /sys/devices/../:00:01.0/mdev_supported_types//. So, let's
+ * strip the common part of the path and let udev chew the relative bit.
+ */
+devpath = udev_device_get_syspath(device);
+relpath = sysfspath + strlen(devpath);
+
+MDEV_GET_SYSFS_ATTR(name, relpath,
+udevGetStringSysfsAttr, &mdev->name);
+MDEV_GET_SYSFS_ATTR(description, relpath,
+udevGetStringSysfsAttr, &mdev->description);
+MDEV_GET_SYSFS_ATTR(device_api, relpath,
+udevGetStringSysfsAttr, &mdev->device_api);
+MDEV_GET_SYSFS_ATTR(avail

[libvirt] [RFC PATCH 11/11] docs: Document the mediated devices within the nodedev driver

2017-03-29 Thread Erik Skultety

Signed-off-by: Erik Skultety 
---
 docs/drvnodedev.html.in | 91 +
 1 file changed, 91 insertions(+)

diff --git a/docs/drvnodedev.html.in b/docs/drvnodedev.html.in
index ed185c3df3..776c88cc87 100644
--- a/docs/drvnodedev.html.in
+++ b/docs/drvnodedev.html.in
@@ -180,5 +180,96 @@
 ...
 
 
+MDEV capability
+
+  A PCI device capable of creating mediated devices will include a nested
+  capability mdev which enumerates all the supported mdev types on the
+  physical device, along with the type attributes available through sysfs.
+  For a more info about mediated devices, refer to the
+  paragraph below.
+
+
+
+
+...
+  
+nvidia
+  
+  
+...
+
+  
+GRID M60-0B
+num_heads=2, frl_config=45, framebuffer=512M,
+max_resolution=2560x1600, max_instance=16
+vfio-pci
+16
+  
+  
+
+...
+  
+
+
+Mediated devices (MDEVs)
+
+  Mediated devices (Since 3.2.0) are software
+  devices defining resource allocation on the backing physical device which
+  in turn allows the parent physical device's resources to be divided into
+  several mediated devices, thus sharing the physical device's performance
+  among multiple guests. Unlike SR-IOV however, where a PCIe device appears
+  as multiple separate PCIe devices on the host's PCI bus, mediated devices
+  only appear on the mdev virtual bus. Therefore, no detach/reattach
+  procedure from/to the host driver procedure is involved even though
+  mediated devices are used in a direct device assignment manner.
+  
+  At the moment, libvirt can only list the available mediated devices on 
the
+  host and display all information libvirt can gather about them, see the
+  examples below. Because mediated devices are instantiated from vendor
+  specific templates, simply called 'types', information about the resource
+  allocation for a specific type is contained within the backing physical
+  parent device (see PCI host devices for an example).
+
+
+Example of a mediated device
+
+
+  mdev_4b20d080_1b54_4048_85b3_a6a62d165c01
+  
/sys/devices/pci:00/:00:02.0/4b20d080-1b54-4048-85b3-a6a62d165c01
+  pci__06_00_0
+  
+vfio_mdev
+  
+  
+
+
+  
+
+
+
+  To see the supported mediated device types on a specific physical device
+  use the following:
+
+
+
+$ ls /sys/class/mdev_bus//mdev_supported_types
+
+
+  To manually instantiate a mediated device, use one of the following as a
+  reference:
+
+
+
+$ uuidgen > 
/sys/class/mdev_bus//mdev_supported_types//create
+...
+$ echo  > 
/sys/class/mdev_bus//mdev_supported_types//create
+
+
+  Manual removal of a mediated device is then performed as follows:
+
+
+
+$ echo 1 > /sys/bus/mdev/devices//remove
+
   
 
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC PATCH 04/11] nodedev: udevProcessPCI: Drop syspath variable

2017-03-29 Thread Erik Skultety

Since we have that information provided by @def which is not a private
object, there is really no need for the variable.

Signed-off-by: Erik Skultety 
---
 src/node_device/node_device_udev.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/node_device/node_device_udev.c 
b/src/node_device/node_device_udev.c
index 976ccad710..36ed92f712 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -328,7 +328,6 @@ static int
 udevProcessPCI(struct udev_device *device,
virNodeDeviceDefPtr def)
 {
-const char *syspath = NULL;
 virNodeDevCapPCIDevPtr pci_dev = &def->caps->data.pci_dev;
 virPCIEDeviceInfoPtr pci_express = NULL;
 virPCIDevicePtr pciDev = NULL;
@@ -336,19 +335,17 @@ udevProcessPCI(struct udev_device *device,
 int ret = -1;
 char *p;
 
-syspath = udev_device_get_syspath(device);
-
 if (udevGetUintProperty(device, "PCI_CLASS", &pci_dev->class, 16) < 0)
 goto cleanup;
 
-if ((p = strrchr(syspath, '/')) == NULL ||
+if ((p = strrchr(def->sysfs_path, '/')) == NULL ||
 virStrToLong_ui(p + 1, &p, 16, &pci_dev->domain) < 0 || p == NULL ||
 virStrToLong_ui(p + 1, &p, 16, &pci_dev->bus) < 0 || p == NULL ||
 virStrToLong_ui(p + 1, &p, 16, &pci_dev->slot) < 0 || p == NULL ||
 virStrToLong_ui(p + 1, &p, 16, &pci_dev->function) < 0) {
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("failed to parse the PCI address from sysfs path: 
'%s'"),
-   syspath);
+   def->sysfs_path);
 goto cleanup;
 }
 
@@ -375,8 +372,7 @@ udevProcessPCI(struct udev_device *device,
 &pci_dev->numa_node, 10) < 0)
 goto cleanup;
 
-if (nodeDeviceSysfsGetPCIRelatedDevCaps(syspath,
-&def->caps->data.pci_dev) < 0)
+if (nodeDeviceSysfsGetPCIRelatedDevCaps(def->sysfs_path, pci_dev) < 0)
 goto cleanup;
 
 if (!(pciDev = virPCIDeviceNew(pci_dev->domain,
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC PATCH 10/11] docs: Provide a nodedev driver stub documentation

2017-03-29 Thread Erik Skultety

There's lot more to document about the nodedev driver, besides PCI and
SR-IOV (even this might need to be extended), but let's start small-ish
and at least have a page for it linked from the drivers.html.

Signed-off-by: Erik Skultety 
---
 docs/drivers.html.in|   6 +-
 docs/drvnodedev.html.in | 184 
 2 files changed, 189 insertions(+), 1 deletion(-)
 create mode 100644 docs/drvnodedev.html.in

diff --git a/docs/drivers.html.in b/docs/drivers.html.in
index be7483b9bc..61993861ee 100644
--- a/docs/drivers.html.in
+++ b/docs/drivers.html.in
@@ -4,7 +4,11 @@
   
 Internal drivers
 
-
+
+  Hypervisor drivers
+  Storage drivers
+  Node device driver
+
 
 
   The libvirt public API delegates its implementation to one or
diff --git a/docs/drvnodedev.html.in b/docs/drvnodedev.html.in
new file mode 100644
index 00..ed185c3df3
--- /dev/null
+++ b/docs/drvnodedev.html.in
@@ -0,0 +1,184 @@
+
+http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
+http://www.w3.org/1999/xhtml";>
+  
+Host device management
+
+
+  Libvirt provides management of both physical and virtual host devices
+  (historically also referred to as node devices) like USB, PCI, SCSI, and
+  network devices. This also includes various virtualization capabilities
+  which the aforementioned devices provide for utilization, for example
+  SR-IOV, NPIV, MDEV, DRM, etc. 
+  
+  The node device driver provides means to list and show details about host
+  devices (virsh nodedev-list,
+  virsh nodedev-dumpxml), which are generic and can be used
+  with all devices. It also provides means to create and destroy devices
+  (virsh nodedev-create, virsh nodedev-destroy)
+  which are meant to be used to create virtual devices, currently only
+  supported by NPIV
+  (http://wiki.libvirt.org/page/NPIV_in_libvirt";>more info about 
NPIV)). 
+  
+  Devices on the host system are arranged in a tree-like hierarchy, with
+  the root node being called computer. The node device driver
+  supports two backends to manage the devices, HAL and udev, with the 
former
+  being deprecated in favour of the latter.
+  The generic format of a host device XML can be seen below.
+  To identify a device both within the host and the device tree hierarchy,
+  the following elements are used:
+
+  
+name
+
+  The device's name will be generated by libvirt using the subsystem,
+  like pci and the device's sysfs basename.
+
+path
+
+  Fully qualified sysfs path to the device.
+
+parent
+
+  This element identifies the parent node in the device hierarchy. The
+  value of the element will correspond with the device parent's
+  name element or computer if the device does
+  not have any parent.
+
+driver
+
+  This elements reports the driver in use for this device. The presence
+  of this element in the output XML depends on whether the underlying
+  device manager (most likely udev) exposes information about the
+  driver.
+
+capability
+
+  Describes the device in terms of feature support. The element has one
+  mandatory attribute type the value of which determines
+  the type of the device. Currently recognized values for the attribute
+  are:
+  system,
+  pci,
+  usb,
+  usb_device,
+  net,
+  scsi,
+  scsi_host (Since 0.4.7),
+  fc_host,
+  vports,
+  scsi_target (Since 0.7.3),
+  storage (Since 1.0.4),
+  scsi_generic (Since 1.0.7),
+  drm (Since 3.1.0), and
+  mdev (Since 3.2.0).
+  This element can be nested in which case it further specifies a
+  device's capability. Refer to specific device types to see more 
values
+  for the type attribute which are exclusive.
+
+  
+
+Basic structure of a node device
+
+
+  pci__00_17_0
+  /sys/devices/pci:00/:00:17.0
+  computer
+  
+ahci
+  
+  
+...
+  
+
+
+
+
+PCI host devices
+
+  capability
+  
+When used as top level element, the supported values for the
+type attribute are pci and
+phys_function (see SR-IOV below).
+  
+
+
+
+  pci__04_00_1
+  /sys/devices/pci:00/:00:06.0/:04:00.1
+  pci__00_06_0
+  
+igb
+  
+  
+0
+4
+0
+1
+82576 Gigabit

[libvirt] [RFC PATCH 06/11] nodedev: Introduce the mdev capability to the nodedev driver structure

2017-03-29 Thread Erik Skultety

Besides updating the capability enum, this patch introduces
'virNodeDevCapMdev' structure which will store everything libvirt can
gather from sysfs about a mediated device. Since we need to report the
info for both the mediated child device it's parent mdev capabilities
(merely the mdev types' attributes), this structure serves in both of
these cases with the difference being that the amount of data it holds
depends on the specific scenario (child vs parent).

Signed-off-by: Erik Skultety 
---
 include/libvirt/libvirt-nodedev.h|  1 +
 src/conf/node_device_conf.c  | 19 ++-
 src/conf/node_device_conf.h  | 19 ++-
 src/conf/virnodedeviceobj.c  |  3 ++-
 src/libvirt-nodedev.c|  1 +
 src/libvirt_private.syms |  1 +
 src/node_device/node_device_driver.c |  1 +
 src/node_device/node_device_udev.c   |  8 +++-
 tools/virsh-nodedev.c|  2 ++
 9 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/include/libvirt/libvirt-nodedev.h 
b/include/libvirt/libvirt-nodedev.h
index 85003903d7..59edf4db02 100644
--- a/include/libvirt/libvirt-nodedev.h
+++ b/include/libvirt/libvirt-nodedev.h
@@ -79,6 +79,7 @@ typedef enum {
 VIR_CONNECT_LIST_NODE_DEVICES_CAP_VPORTS= 1 << 10, /* Capable of 
vport */
 VIR_CONNECT_LIST_NODE_DEVICES_CAP_SCSI_GENERIC  = 1 << 11, /* Capable of 
scsi_generic */
 VIR_CONNECT_LIST_NODE_DEVICES_CAP_DRM   = 1 << 12, /* DRM device */
+VIR_CONNECT_LIST_NODE_DEVICES_CAP_MDEV  = 1 << 13, /* Mediated 
device */
 } virConnectListAllNodeDeviceFlags;
 
 int virConnectListAllNodeDevices (virConnectPtr conn,
diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 72fb9a5611..03d7993ab1 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -60,7 +60,8 @@ VIR_ENUM_IMPL(virNodeDevCap, VIR_NODE_DEV_CAP_LAST,
   "fc_host",
   "vports",
   "scsi_generic",
-  "drm")
+  "drm",
+  "mdev")
 
 VIR_ENUM_IMPL(virNodeDevNetCap, VIR_NODE_DEV_CAP_NET_LAST,
   "80203",
@@ -542,6 +543,7 @@ virNodeDeviceDefFormat(const virNodeDeviceDef *def)
 break;
 case VIR_NODE_DEV_CAP_FC_HOST:
 case VIR_NODE_DEV_CAP_VPORTS:
+case VIR_NODE_DEV_CAP_MDEV:
 case VIR_NODE_DEV_CAP_LAST:
 break;
 }
@@ -1591,6 +1593,7 @@ virNodeDevCapsDefParseXML(xmlXPathContextPtr ctxt,
 case VIR_NODE_DEV_CAP_FC_HOST:
 case VIR_NODE_DEV_CAP_VPORTS:
 case VIR_NODE_DEV_CAP_SCSI_GENERIC:
+case VIR_NODE_DEV_CAP_MDEV:
 case VIR_NODE_DEV_CAP_LAST:
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("unknown capability type '%d' for '%s'"),
@@ -1905,6 +1908,7 @@ virNodeDevCapsDefFree(virNodeDevCapsDefPtr caps)
 case VIR_NODE_DEV_CAP_SCSI_GENERIC:
 VIR_FREE(data->sg.path);
 break;
+case VIR_NODE_DEV_CAP_MDEV:
 case VIR_NODE_DEV_CAP_DRM:
 case VIR_NODE_DEV_CAP_FC_HOST:
 case VIR_NODE_DEV_CAP_VPORTS:
@@ -1917,6 +1921,19 @@ virNodeDevCapsDefFree(virNodeDevCapsDefPtr caps)
 }
 
 
+void virNodeDevCapMdevFree(virNodeDevCapMdevPtr mdev)
+{
+if (!mdev)
+return;
+
+VIR_FREE(mdev->type);
+VIR_FREE(mdev->name);
+VIR_FREE(mdev->description);
+VIR_FREE(mdev->device_api);
+VIR_FREE(mdev);
+}
+
+
 /* virNodeDeviceGetParentName
  * @conn: Connection pointer
  * @nodedev_name: Node device to lookup
diff --git a/src/conf/node_device_conf.h b/src/conf/node_device_conf.h
index a5d5cdd2a5..b7db35dd50 100644
--- a/src/conf/node_device_conf.h
+++ b/src/conf/node_device_conf.h
@@ -64,6 +64,7 @@ typedef enum {
 VIR_NODE_DEV_CAP_VPORTS,   /* HBA which is capable of vports */
 VIR_NODE_DEV_CAP_SCSI_GENERIC,  /* SCSI generic device */
 VIR_NODE_DEV_CAP_DRM,   /* DRM device */
+VIR_NODE_DEV_CAP_MDEV,  /* Mediated device */
 
 VIR_NODE_DEV_CAP_LAST
 } virNodeDevCapType;
@@ -131,6 +132,17 @@ struct _virNodeDevCapSystem {
 virNodeDevCapSystemFirmware firmware;
 };
 
+typedef struct _virNodeDevCapMdev virNodeDevCapMdev;
+typedef virNodeDevCapMdev *virNodeDevCapMdevPtr;
+struct _virNodeDevCapMdev {
+char *type;
+char *name;
+char *description;
+char *device_api;
+unsigned int available_instances;
+unsigned int iommuGroupNumber;
+};
+
 typedef struct _virNodeDevCapPCIDev virNodeDevCapPCIDev;
 typedef virNodeDevCapPCIDev *virNodeDevCapPCIDevPtr;
 struct _virNodeDevCapPCIDev {
@@ -262,6 +274,7 @@ struct _virNodeDevCapData {
 virNodeDevCapStorage storage;
 virNodeDevCapSCSIGeneric sg;
 virNodeDevCapDRM drm;
+virNodeDevCapMdev mdev;
 };
 };
 
@@ -338,6 +351,9 @@ virNodeDeviceDefFree(virNodeDeviceDefPtr def);
 void
 virNodeDevCapsDefFree(virNodeDevCapsDefPtr caps);
 
+void
+virNodeDevCapMdevFree(virNodeDevCapMdevPtr mdev);
+
 # de

[libvirt] [RFC PATCH 05/11] docs: Use our XSLT template to generate list of supported pool types

2017-03-29 Thread Erik Skultety

Since we do have this template at hand, why not using it wherever
possible. Also, just to be grammatically correct, let's use singular,
aka 'pool' instead of plural in the enumerated list of supported types.

Signed-off-by: Erik Skultety 
---
 docs/storage.html.in | 62 ++--
 1 file changed, 11 insertions(+), 51 deletions(-)

diff --git a/docs/storage.html.in b/docs/storage.html.in
index 5e18f02c58..2487ede67b 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -83,47 +83,7 @@
 
   Libvirt supports the following storage pool types:
 
-
-  
-Directory backend
-  
-  
-Local filesystem backend
-  
-  
-Network filesystem backend
-  
-  
-Logical backend
-  
-  
-Disk backend
-  
-  
-iSCSI backend
-  
-  
-SCSI backend
-  
-  
-Multipath backend
-  
-  
-RBD (RADOS Block Device) backend
-  
-  
-Sheepdog backend
-  
-  
-Gluster backend
-  
-  
-ZFS backend
-  
-  
-Virtuozzo storage backend
-  
-
+
 
 Directory pool
 
@@ -306,7 +266,7 @@
 
 
 
-Logical volume pools
+Logical volume pool
 
   This provides a pool based on an LVM volume group. For a
   pre-defined LVM volume group, simply providing the group
@@ -343,7 +303,7 @@
 
 
 
-Disk volume pools
+Disk volume pool
 
   This provides a pool based on a physical disk. Volumes are created
   by adding partitions to the disk. Disk pools have constraints
@@ -434,7 +394,7 @@
 
 
 
-iSCSI volume pools
+iSCSI volume pool
 
   This provides a pool based on an iSCSI target. Volumes must be
   pre-allocated on the iSCSI server, and cannot be created via
@@ -473,7 +433,7 @@
   The iSCSI volume pool does not use the volume format type element.
 
 
-SCSI volume pools
+SCSI volume pool
 
   This provides a pool based on a SCSI HBA. Volumes are preexisting SCSI
   LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX names
@@ -505,7 +465,7 @@
   The SCSI volume pool does not use the volume format type element.
 
 
-Multipath pools
+Multipath pool
 
   This provides a pool that contains all the multipath devices on the
   host. Therefore, only one Multipath pool may be configured per host.
@@ -538,7 +498,7 @@
   The Multipath volume pool does not use the volume format type element.
 
 
-RBD pools
+RBD pool
 
   This storage driver provides a pool which contains all RBD
   images in a RADOS pool.  RBD (RADOS Block Device) is part
@@ -611,7 +571,7 @@
   The RBD pool does not use the volume format type element.
 
 
-Sheepdog pools
+Sheepdog pool
 
   This provides a pool based on a Sheepdog Cluster.
   Sheepdog is a distributed storage system for QEMU/KVM.
@@ -670,7 +630,7 @@
   The Sheepdog pool does not use the volume format type element.
 
 
-Gluster pools
+Gluster pool
 
   This provides a pool based on native Gluster access.  Gluster is
   a distributed file system that can be exposed to the user via
@@ -756,7 +716,7 @@
   pool type.
 
 
-ZFS pools
+ZFS pool
 
   This provides a pool based on the ZFS filesystem. Initially it was 
developed
   for FreeBSD, and since 1.3.2 experimental 
support
@@ -794,7 +754,7 @@
 
   The ZFS volume pool does not use the volume format type element.
 
-Vstorage pools
+Vstorage pool
 
   This provides a pool based on Virtuozzo storage. Virtuozzo Storage is
   a highly available distributed software-defined storage with built-in
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC PATCH 02/11] nodedev: Make use of the compile-time missing enum in switch error

2017-03-29 Thread Erik Skultety

So udevGetDeviceDetails was one those functions using an enum in a
switch, but since it had a 'default' case, compiler didn't warn about an
unhandled enum. Moreover, the error about an unsupported device type
reported in the default case is unnecessary, since by the time we get
there, udevGetDeviceType (which was called before) already made sure
that any unrecognized device types had been handled properly.

Signed-off-by: Erik Skultety 
---
 src/node_device/node_device_udev.c | 45 +-
 1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/src/node_device/node_device_udev.c 
b/src/node_device/node_device_udev.c
index 4a837e04dc..976ccad710 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -1079,50 +1079,35 @@ static int
 udevGetDeviceDetails(struct udev_device *device,
  virNodeDeviceDefPtr def)
 {
-int ret = 0;
-
 switch (def->caps->data.type) {
-case VIR_NODE_DEV_CAP_SYSTEM:
-/* There's no libudev equivalent of system, so ignore it. */
-break;
 case VIR_NODE_DEV_CAP_PCI_DEV:
-ret = udevProcessPCI(device, def);
-break;
+return udevProcessPCI(device, def);
 case VIR_NODE_DEV_CAP_USB_DEV:
-ret = udevProcessUSBDevice(device, def);
-break;
+return udevProcessUSBDevice(device, def);
 case VIR_NODE_DEV_CAP_USB_INTERFACE:
-ret = udevProcessUSBInterface(device, def);
-break;
+return udevProcessUSBInterface(device, def);
 case VIR_NODE_DEV_CAP_NET:
-ret = udevProcessNetworkInterface(device, def);
-break;
+return udevProcessNetworkInterface(device, def);
 case VIR_NODE_DEV_CAP_SCSI_HOST:
-ret = udevProcessSCSIHost(device, def);
-break;
+return udevProcessSCSIHost(device, def);
 case VIR_NODE_DEV_CAP_SCSI_TARGET:
-ret = udevProcessSCSITarget(device, def);
-break;
+return udevProcessSCSITarget(device, def);
 case VIR_NODE_DEV_CAP_SCSI:
-ret = udevProcessSCSIDevice(device, def);
-break;
+return udevProcessSCSIDevice(device, def);
 case VIR_NODE_DEV_CAP_STORAGE:
-ret = udevProcessStorage(device, def);
-break;
+return udevProcessStorage(device, def);
 case VIR_NODE_DEV_CAP_SCSI_GENERIC:
-ret = udevProcessSCSIGeneric(device, def);
-break;
+return udevProcessSCSIGeneric(device, def);
 case VIR_NODE_DEV_CAP_DRM:
-ret = udevProcessDRMDevice(device, def);
-break;
-default:
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("Unknown device type %d"), def->caps->data.type);
-ret = -1;
+return udevProcessDRMDevice(device, def);
+case VIR_NODE_DEV_CAP_SYSTEM:
+case VIR_NODE_DEV_CAP_FC_HOST:
+case VIR_NODE_DEV_CAP_VPORTS:
+case VIR_NODE_DEV_CAP_LAST:
 break;
 }
 
-return ret;
+return 0;
 }
 
 
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC PATCH 03/11] conf: nodedev: Split virNodeDeviceDefFormat into more functions

2017-03-29 Thread Erik Skultety

Make the code look cleaner by moving the capability specific bits into
separate functions.

Signed-off-by: Erik Skultety 
---
 src/conf/node_device_conf.c | 578 
 1 file changed, 322 insertions(+), 256 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 7d0baa9d1a..72fb9a5611 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -155,6 +155,320 @@ virPCIEDeviceInfoFormat(virBufferPtr buf,
 }
 
 
+static void
+virNodeDeviceCapSystemDefFormat(virBufferPtr buf,
+const virNodeDevCapData *data)
+{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+
+if (data->system.product_name)
+virBufferEscapeString(buf, "%s\n",
+  data->system.product_name);
+virBufferAddLit(buf, "\n");
+virBufferAdjustIndent(buf, 2);
+if (data->system.hardware.vendor_name)
+virBufferEscapeString(buf, "%s\n",
+  data->system.hardware.vendor_name);
+if (data->system.hardware.version)
+virBufferEscapeString(buf, "%s\n",
+  data->system.hardware.version);
+if (data->system.hardware.serial)
+virBufferEscapeString(buf, "%s\n",
+  data->system.hardware.serial);
+virUUIDFormat(data->system.hardware.uuid, uuidstr);
+virBufferAsprintf(buf, "%s\n", uuidstr);
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+
+virBufferAddLit(buf, "\n");
+virBufferAdjustIndent(buf, 2);
+if (data->system.firmware.vendor_name)
+virBufferEscapeString(buf, "%s\n",
+  data->system.firmware.vendor_name);
+if (data->system.firmware.version)
+virBufferEscapeString(buf, "%s\n",
+  data->system.firmware.version);
+if (data->system.firmware.release_date)
+virBufferEscapeString(buf, "%s\n",
+  data->system.firmware.release_date);
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+}
+
+
+static void
+virNodeDeviceCapPCIDefFormat(virBufferPtr buf,
+ const virNodeDevCapData *data)
+{
+size_t i;
+
+virBufferAsprintf(buf, "%d\n",
+  data->pci_dev.domain);
+virBufferAsprintf(buf, "%d\n", data->pci_dev.bus);
+virBufferAsprintf(buf, "%d\n",
+  data->pci_dev.slot);
+virBufferAsprintf(buf, "%d\n",
+  data->pci_dev.function);
+virBufferAsprintf(buf, "pci_dev.product);
+if (data->pci_dev.product_name)
+virBufferEscapeString(buf, ">%s\n",
+  data->pci_dev.product_name);
+else
+virBufferAddLit(buf, " />\n");
+virBufferAsprintf(buf, "pci_dev.vendor);
+if (data->pci_dev.vendor_name)
+virBufferEscapeString(buf, ">%s\n",
+  data->pci_dev.vendor_name);
+else
+virBufferAddLit(buf, " />\n");
+if (data->pci_dev.flags & VIR_NODE_DEV_CAP_FLAG_PCI_PHYSICAL_FUNCTION) {
+virBufferAddLit(buf, "\n");
+virBufferAdjustIndent(buf, 2);
+virBufferAsprintf(buf,
+  "\n",
+  data->pci_dev.physical_function->domain,
+  data->pci_dev.physical_function->bus,
+  data->pci_dev.physical_function->slot,
+  data->pci_dev.physical_function->function);
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+}
+if (data->pci_dev.flags & VIR_NODE_DEV_CAP_FLAG_PCI_VIRTUAL_FUNCTION) {
+virBufferAddLit(buf, "pci_dev.max_virtual_functions)
+virBufferAsprintf(buf, " maxCount='%u'",
+  data->pci_dev.max_virtual_functions);
+if (data->pci_dev.num_virtual_functions == 0) {
+virBufferAddLit(buf, "/>\n");
+} else {
+virBufferAddLit(buf, ">\n");
+virBufferAdjustIndent(buf, 2);
+for (i = 0; i < data->pci_dev.num_virtual_functions; i++) {
+virBufferAsprintf(buf,
+  "\n",
+  data->pci_dev.virtual_functions[i]->domain,
+  data->pci_dev.virtual_functions[i]->bus,
+  data->pci_dev.virtual_functions[i]->slot,
+  
data->pci_dev.virtual_functions[i]->function);
+}
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+}
+}
+if (data->pci_dev.hdrType) {
+virBufferAsprintf(buf, "\n",
+  virPCIHeaderTypeToString(data->pci_dev.hdrType));
+}
+if (data->pci_dev.nIommuGroupDevices) {
+virBufferAsprintf(buf, "\n",
+  data->pci_dev.iommuGroupNumber);
+virBufferAdjustIndent(buf,

[libvirt] [RFC PATCH 07/11] nodedev: Fill in the mdev info for the parent PCI device

2017-03-29 Thread Erik Skultety

The parent device needs to report the generic stuff about the supported
mediated devices types, like device API, available instances, and
description which might hold some useful data about supported
resolutions for the type given, framebuffer size, etc. Unfortunately,
these are not standardized yet to be considered for separate elements.

Signed-off-by: Erik Skultety 
---
 src/conf/node_device_conf.h|   2 +
 src/node_device/node_device_udev.c | 115 +
 2 files changed, 117 insertions(+)

diff --git a/src/conf/node_device_conf.h b/src/conf/node_device_conf.h
index b7db35dd50..d521dd9a4c 100644
--- a/src/conf/node_device_conf.h
+++ b/src/conf/node_device_conf.h
@@ -166,6 +166,8 @@ struct _virNodeDevCapPCIDev {
 int numa_node;
 virPCIEDeviceInfoPtr pci_express;
 int hdrType; /* enum virPCIHeaderType or -1 */
+virNodeDevCapMdevPtr *mdevs;
+size_t nmdevs;
 };
 
 typedef struct _virNodeDevCapUSBDev virNodeDevCapUSBDev;
diff --git a/src/node_device/node_device_udev.c 
b/src/node_device/node_device_udev.c
index dbbd8e5d06..be031fa5a8 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -324,6 +324,115 @@ udevTranslatePCIIds(unsigned int vendor,
 return 0;
 }
 
+#define MDEV_GET_SYSFS_ATTR(attr, cb, ...)  \
+do {\
+if (virAsprintf(&attrpath, "%s/%s", relpath, #attr) < 0)\
+goto cleanup;   \
+\
+if (cb(device, attrpath, __VA_ARGS__) < 0)  \
+goto cleanup;   \
+} while (0) \
+
+
+static int
+udevGetMdevCaps(struct udev_device *device,
+const char *sysfspath,
+virNodeDevCapMdevPtr mdev)
+{
+int ret = -1;
+char *attrpath = NULL;  /* relative path to the actual sysfs attribute */
+const char *devpath = NULL;   /* base sysfs path as reported by udev */
+const char *relpath = NULL;   /* diff between @sysfspath and @devpath */
+char *tmp = NULL;
+
+
+/* UDEV doesn't report attributes under subdirectories but can query them
+ * if specified as relative paths to the device's base path,
+ * e.g. /sys/devices/../:00:01.0/ is the device's base path as udev
+ * reports it, but we're interested in attributes under
+ * /sys/devices/../:00:01.0/mdev_supported_types//. So, let's
+ * strip the common part of the path and let udev chew the relative bit.
+ */
+devpath = udev_device_get_syspath(device);
+relpath = sysfspath + strlen(devpath);
+
+/* When calling from the mdev child device, @sysfspath is a symbolic link
+ * to the actual mdev type (rather than a physical path), so we need to
+ * resolve it in order to get the type's name.
+ */
+if (virFileResolveLink(sysfspath, &tmp) < 0)
+goto cleanup;
+
+if (VIR_STRDUP(mdev->type, last_component(tmp)) < 0)
+goto cleanup;
+
+MDEV_GET_SYSFS_ATTR(name, udevGetStringSysfsAttr,
+&mdev->name);
+MDEV_GET_SYSFS_ATTR(description, udevGetStringSysfsAttr,
+&mdev->description);
+MDEV_GET_SYSFS_ATTR(device_api, udevGetStringSysfsAttr,
+&mdev->device_api);
+MDEV_GET_SYSFS_ATTR(available_instances, udevGetUintSysfsAttr,
+&mdev->available_instances, 10);
+
+ret = 0;
+ cleanup:
+VIR_FREE(attrpath);
+VIR_FREE(tmp);
+return ret;
+}
+#undef MDEV_GET_SYSFS_ATTR
+
+
+static int
+udevPCIGetMdevCaps(struct udev_device *device,
+   virNodeDevCapPCIDevPtr pcidata)
+{
+int ret = -1;
+DIR *dir = NULL;
+struct dirent *entry;
+char *path = NULL;
+char *tmppath = NULL;
+virNodeDevCapMdevPtr mdev = NULL;
+
+if (virAsprintf(&path, "%s/mdev_supported_types",
+udev_device_get_syspath(device)) < 0)
+return -1;
+
+if ((ret = virDirOpenIfExists(&dir, path)) <= 0)
+goto cleanup;
+
+if (VIR_ALLOC(pcidata->mdevs) < 0)
+goto cleanup;
+
+/* since udev doesn't provide means to list other than top-level
+ * attributes, we need to scan the subdirectories ourselves
+ */
+while ((ret = virDirRead(dir, &entry, path)) > 0) {
+if (VIR_ALLOC(mdev) < 0)
+goto cleanup;
+
+if (virAsprintf(&tmppath, "%s/%s", path, entry->d_name) < 0)
+goto cleanup;
+
+if (udevGetMdevCaps(device, tmppath, mdev) < 0)
+goto cleanup;
+
+if (VIR_APPEND_ELEMENT(pcidata->mdevs, pcidata->nmdevs, mdev) < 0)
+goto cleanup;
+
+VIR_FREE(tmppath);
+}
+
+ret = 0;
+ cleanup:
+VIR_DIR_CLOSE(dir

[libvirt] [RFC PATCH 09/11] nodedev: Format the mdev capability of the PCI parent device

2017-03-29 Thread Erik Skultety

This introduces a new nested capability element of type 'mdev' with the
resulting XML of the following format:


...
  
  ...

  
optional, raw, unstructured resource allocation data

vfio-pci
NUM
  
  ...
  
  ...
  

  
...


Signed-off-by: Erik Skultety 
---
 src/conf/node_device_conf.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 1f13484d9b..99211de6f3 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -264,6 +264,30 @@ virNodeDeviceCapPCIDefFormat(virBufferPtr buf,
 virBufferAsprintf(buf, "\n",
   virPCIHeaderTypeToString(data->pci_dev.hdrType));
 }
+if (data->pci_dev.mdevs) {
+virBufferAddLit(buf, "\n");
+virBufferAdjustIndent(buf, 2);
+for (i = 0; i < data->pci_dev.nmdevs; i++) {
+virNodeDevCapMdevPtr mdev = data->pci_dev.mdevs[i];
+virBufferEscapeString(buf, "\n", mdev->type);
+virBufferAdjustIndent(buf, 2);
+if (mdev->name)
+virBufferAsprintf(buf, "%s\n",
+  mdev->name);
+if (mdev->description)
+virBufferAsprintf(buf, "%s\n",
+  mdev->description);
+virBufferAsprintf(buf, "%s\n",
+  mdev->device_api);
+virBufferAsprintf(buf,
+  
"%u\n",
+  mdev->available_instances);
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+}
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+}
 if (data->pci_dev.nIommuGroupDevices) {
 virBufferAsprintf(buf, "\n",
   data->pci_dev.iommuGroupNumber);
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC PATCH 01/11] nodedev: Fix guideline violations in nodedev modules

2017-03-29 Thread Erik Skultety

We recently started to enforce certain guideline rule a bit more, e.g.
functions delimited by 2 newlines in *.c, by 1 newline in *.h, return
types on a separate line, etc. This patch adjusts these issues in all
nodedev modules.

Signed-off-by: Erik Skultety 
---
 src/node_device/node_device_driver.c  |  29 +++-
 src/node_device/node_device_driver.h  |  82 +++
 src/node_device/node_device_hal.c |   9 ++
 src/node_device/node_device_linux_sysfs.c |   1 +
 src/node_device/node_device_linux_sysfs.h |   9 +-
 src/node_device/node_device_udev.c| 233 ++
 6 files changed, 238 insertions(+), 125 deletions(-)

diff --git a/src/node_device/node_device_driver.c 
b/src/node_device/node_device_driver.c
index 99f7bc5476..9b1c5bb5e9 100644
--- a/src/node_device/node_device_driver.c
+++ b/src/node_device/node_device_driver.c
@@ -47,7 +47,8 @@
 
 virNodeDeviceDriverStatePtr driver;
 
-static int update_caps(virNodeDeviceObjPtr dev)
+static int
+update_caps(virNodeDeviceObjPtr dev)
 {
 virNodeDevCapsDefPtr cap = dev->def->caps;
 
@@ -101,7 +102,8 @@ static int update_caps(virNodeDeviceObjPtr dev)
  * the driver name for a device each time its entry is used, both for
  * udev *and* HAL backends.
  */
-static int update_driver_name(virNodeDeviceObjPtr dev)
+static int
+update_driver_name(virNodeDeviceObjPtr dev)
 {
 char *driver_link = NULL;
 char *devpath = NULL;
@@ -138,22 +140,28 @@ static int update_driver_name(virNodeDeviceObjPtr dev)
 }
 #else
 /* XXX: Implement me for non-linux */
-static int update_driver_name(virNodeDeviceObjPtr dev ATTRIBUTE_UNUSED)
+static int
+update_driver_name(virNodeDeviceObjPtr dev ATTRIBUTE_UNUSED)
 {
 return 0;
 }
 #endif
 
 
-void nodeDeviceLock(void)
+void
+nodeDeviceLock(void)
 {
 virMutexLock(&driver->lock);
 }
-void nodeDeviceUnlock(void)
+
+
+void
+nodeDeviceUnlock(void)
 {
 virMutexUnlock(&driver->lock);
 }
 
+
 int
 nodeNumOfDevices(virConnectPtr conn,
  const char *cap,
@@ -182,6 +190,7 @@ nodeNumOfDevices(virConnectPtr conn,
 return ndevs;
 }
 
+
 int
 nodeListDevices(virConnectPtr conn,
 const char *cap,
@@ -222,6 +231,7 @@ nodeListDevices(virConnectPtr conn,
 return -1;
 }
 
+
 int
 nodeConnectListAllNodeDevices(virConnectPtr conn,
   virNodeDevicePtr **devices,
@@ -242,6 +252,7 @@ nodeConnectListAllNodeDevices(virConnectPtr conn,
 return ret;
 }
 
+
 virNodeDevicePtr
 nodeDeviceLookupByName(virConnectPtr conn, const char *name)
 {
@@ -500,6 +511,7 @@ nodeDeviceListCaps(virNodeDevicePtr dev, char **const 
names, int maxnames)
 return ret;
 }
 
+
 static int
 get_time(time_t *t)
 {
@@ -565,6 +577,7 @@ find_new_device(virConnectPtr conn, const char *wwnn, const 
char *wwpn)
 return dev;
 }
 
+
 virNodeDevicePtr
 nodeDeviceCreateXML(virConnectPtr conn,
 const char *xmlDesc,
@@ -663,6 +676,7 @@ nodeDeviceDestroy(virNodeDevicePtr dev)
 return ret;
 }
 
+
 int
 nodeConnectNodeDeviceEventRegisterAny(virConnectPtr conn,
   virNodeDevicePtr dev,
@@ -684,6 +698,7 @@ nodeConnectNodeDeviceEventRegisterAny(virConnectPtr conn,
 return callbackID;
 }
 
+
 int
 nodeConnectNodeDeviceEventDeregisterAny(virConnectPtr conn,
 int callbackID)
@@ -704,7 +719,9 @@ nodeConnectNodeDeviceEventDeregisterAny(virConnectPtr conn,
 return ret;
 }
 
-int nodedevRegister(void)
+
+int
+nodedevRegister(void)
 {
 #ifdef WITH_UDEV
 return udevNodeRegister();
diff --git a/src/node_device/node_device_driver.h 
b/src/node_device/node_device_driver.h
index bc8af8a9e7..0f55e7b71e 100644
--- a/src/node_device/node_device_driver.h
+++ b/src/node_device/node_device_driver.h
@@ -30,37 +30,67 @@
 
 # define LINUX_NEW_DEVICE_WAIT_TIME 60
 
+extern virNodeDeviceDriverStatePtr driver;
+
 # ifdef WITH_HAL
-int halNodeRegister(void);
+int
+halNodeRegister(void);
 # endif
 # ifdef WITH_UDEV
-int udevNodeRegister(void);
+int
+udevNodeRegister(void);
 # endif
 
-void nodeDeviceLock(void);
-void nodeDeviceUnlock(void);
-
-extern virNodeDeviceDriverStatePtr driver;
-
-int nodedevRegister(void);
-
-int nodeNumOfDevices(virConnectPtr conn, const char *cap, unsigned int flags);
-int nodeListDevices(virConnectPtr conn, const char *cap, char **const names,
-int maxnames, unsigned int flags);
-int nodeConnectListAllNodeDevices(virConnectPtr conn,
-  virNodeDevicePtr **devices,
-  unsigned int flags);
-virNodeDevicePtr nodeDeviceLookupByName(virConnectPtr conn, const char *name);
-virNodeDevicePtr nodeDeviceLookupSCSIHostByWWN(virConnectPtr conn,
-   const char *wwnn,
-   const char *wwpn,
-   unsigned int flags);
-char *nodeDeviceGetXMLDesc(virNodeDevicePtr dev

[libvirt] [RFC PATCH 00/11] Add mdev reporting capability to the nodedev driver

2017-03-29 Thread Erik Skultety

This series enables the node device driver to report information about the
existing mediated devices on the host. There is no device creation involved
yet. The information reported by the node device driver is split into two
parts, one that is reported within the physical parent's capabilities
(the generic stuff that comes from the mdev types' sysfs attributes, note the
 'description' attribute which is verbatim - raw,unstructured string) and the
other that is reported within the mdev child device and merely contains the
mdev type id, which the device was instantiated from, and the iommu group
number.

Basically, the format of the XML I went for is as follows:

PCI parent:

  pci__06_00_0
  /sys/devices/.../:06:00.0
  pci__05_08_0
  ...
  
...

  
GRID M60-0B
num_heads=2, frl_config=45, framebuffer=512M, 
max_resolution=2560x1600, max_instance=16
vfio-pci
16
  
...


  

...
  


mdev child:

  mdev_ef1212ff_ff23_4534_ffcd_01ff12017801
  /sys/devices/.../ef1212ff-ff23-4534-ffcd-01ff12017801
  pci__06_00_0
  
vfio_mdev
  
  


  


Also, since we didn't have any node device driver documentation, I created a
stub (comments are very welcome, you can shred it to pieces ;)) focusing on the
PCI devices and then adding the mdev part into that. As I said, it's still a
stub that needs lots of work on it, namely adding USBs and SCSI devices, but I
figured that the fact some parts are missing should not be a show stopper for
the nodedev-mdev patches.

Thanks,
Erik

Erik Skultety (11):
  nodedev: Fix guideline violations in nodedev modules
  nodedev: Make use of the compile-time missing enum in switch error
  conf: nodedev: Split virNodeDeviceDefFormat into more functions
  nodedev: udevProcessPCI: Drop syspath variable
  docs: Use our XSLT template to generate list of supported pool types
  nodedev: Introduce the mdev capability to the nodedev driver structure
  nodedev: Fill in the mdev info for the parent PCI device
  nodedev: Introduce udevProcessMediatedDevice
  nodedev: Format the mdev capability of the PCI parent device
  docs: Provide a nodedev driver stub documentation
  docs: Document the mediated devices within the nodedev driver

 docs/drivers.html.in  |   6 +-
 docs/drvnodedev.html.in   | 275 +
 docs/storage.html.in  |  62 +--
 include/libvirt/libvirt-nodedev.h |   1 +
 src/conf/node_device_conf.c   | 625 ++
 src/conf/node_device_conf.h   |  21 +-
 src/conf/virnodedeviceobj.c   |   3 +-
 src/libvirt-nodedev.c |   1 +
 src/libvirt_private.syms  |   1 +
 src/node_device/node_device_driver.c  |  30 +-
 src/node_device/node_device_driver.h  |  82 ++--
 src/node_device/node_device_hal.c |   9 +
 src/node_device/node_device_linux_sysfs.c |   1 +
 src/node_device/node_device_linux_sysfs.h |   9 +-
 src/node_device/node_device_udev.c| 456 --
 tools/virsh-nodedev.c |   2 +
 16 files changed, 1110 insertions(+), 474 deletions(-)
 create mode 100644 docs/drvnodedev.html.in

--
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] util: Add more virsysfs functions for handling resctrl sysfs

2017-03-29 Thread Martin Kletzander


On Wed, Mar 29, 2017 at 05:44:36PM +0800, Eli Qiao wrote:

Extended /sys/fs/resctrl sysfs handling.



This looks good, few notes below.


Signed-off-by: Eli Qiao 
---
src/libvirt_private.syms |  4 ++
src/util/virsysfs.c  | 98 +++-
src/util/virsysfs.h  | 15 
3 files changed, 116 insertions(+), 1 deletion(-)

diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index b551cb8..e07ae79 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2631,6 +2631,10 @@ virSysfsGetValueBitmap;
virSysfsGetValueInt;
virSysfsGetValueString;
virSysfsSetSystemPath;
+virSysfsGetResctrlString;
+virSysfsGetResctrlUint;
+virSysfsGetResctrlInfoString;
+virSysfsGetResCtrInfoUint;



This will not pass the tests.



# util/virsysinfo.h
diff --git a/src/util/virsysfs.c b/src/util/virsysfs.c
index 7a98b48..d1be289 100644
--- a/src/util/virsysfs.c
+++ b/src/util/virsysfs.c
@@ -36,8 +36,10 @@ VIR_LOG_INIT("util.sysfs");

#define VIR_SYSFS_VALUE_MAXLEN 8192
#define SYSFS_SYSTEM_PATH "/sys/devices/system"
+#define SYSFS_RESCTRL_PATH "/sys/fs/resctrl"

static const char *sysfs_system_path = SYSFS_SYSTEM_PATH;
+static const char *sysfs_resctrl_path = SYSFS_RESCTRL_PATH;


void virSysfsSetSystemPath(const char *path)
@@ -48,13 +50,26 @@ void virSysfsSetSystemPath(const char *path)
sysfs_system_path = SYSFS_SYSTEM_PATH;
}

-
const char *
virSysfsGetSystemPath(void)
{
return sysfs_system_path;
}

+void virSysfsSetResctrlPath(const char *path)
+{
+if (path)
+sysfs_resctrl_path  = path;
+else
+sysfs_resctrl_path = SYSFS_RESCTRL_PATH;
+}
+
+const char *
+virSysfsGetResctrlPath(void)
+{
+return sysfs_resctrl_path;
+}
+


This will not compile (no previous declaration)


int
virSysfsGetValueInt(const char *file,
int *value)
@@ -227,3 +242,84 @@ virSysfsGetNodeValueBitmap(unsigned int node,
VIR_FREE(path);
return ret;
}
+
+int
+virSysfsGetResctrlString(const char* file,
+ char **value)
+{
+chat *path = NULL;
+int ret = -1;

Some empty line here ...

+if (virAsprintf(&path, "%s/%s", sysfs_resctrl_path, file) < 0)

... and there would be nice to read.

+if (!virFileExists(path)) {
+ret = -2;
+goto cleanup;
+}
+
+if (virFileReadAll(path, VIR_SYSFS_VALUE_MAXLEN, value) < 0)
+goto cleanup;
+
+ret = 0;
+
+ cleanup:
+VIR_FREE(path);
+return ret;
+}
+
+int
+virSysfsGetResctrlUint(const char* file,
+   unsigned int **value)
+{
+chat *path = NULL;
+int ret = -1;



+if (virAsprintf(&path, "%s/%s", sysfs_resctrl_path, file) < 0)



+if (!virFileExists(path)) {
+ret = -2;
+goto cleanup;
+}
+
+ret = virFileReadValueUint(path, value);
+
+ cleanup:
+VIR_FREE(path);
+return ret;
+}
+
+int
+virSysfsGetResctrlInfoString(const char* file,
+ char **value)
+{
+chat *path = NULL;
+int ret = -1;



+if (virAsprintf(&path, "%s/info/%s", sysfs_resctrl_path, file) < 0)
+return -1;
+
+if (!virFileExists(path)) {
+ret = -2;
+goto cleanup;
+}
+
+if (virFileReadAll(path, VIR_SYSFS_VALUE_MAXLEN, value) < 0)
+goto cleanup;
+
+ret = 0;
+
+ cleanup:
+VIR_FREE(path);
+return ret;
+}
+
+int
+virSysfsGetResCtrInfoUint(const char *file,
+  unsigned int *value)
+{
+char *path = NULL;
+int ret = -1;
+
+if (virAsprintf(&path, "%s/info/%s", sysfs_resctrl_path, file) < 0)
+return -1;
+
+ret = virFileReadValueUint(path, value);
+
+VIR_FREE(path);
+return ret;
+}
diff --git a/src/util/virsysfs.h b/src/util/virsysfs.h
index cd871ff..81a27c2 100644
--- a/src/util/virsysfs.h
+++ b/src/util/virsysfs.h
@@ -67,4 +67,19 @@ virSysfsGetNodeValueBitmap(unsigned int cpu,
   const char *file,
   virBitmapPtr *value);

+int
+virSysfsGetResctrlString(const char* file,
+ char **value);
+
+int
+virSysfsGetResctrlUint(const char* file,
+   unsigned int **value);
+
+int
+virSysfsGetResctrlInfoString(const char* file,
+ char **value);
+
+int
+virSysfsGetResCtrInfoUint(const char *file,
+  unsigned int *value);
#endif /* __VIR_SYSFS_H__*/
--
1.9.1



signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Martin Kletzander


On Wed, Mar 29, 2017 at 05:59:47PM +0800, Eli Qiao wrote:



On Wednesday, 29 March 2017 at 5:47 PM, Martin Kletzander wrote:


On Wed, Mar 29, 2017 at 05:31:42PM +0800, Eli Qiao wrote:
>
>
> --
> Best regards
> Eli
>
> 天涯无处不重逢
> a leaf duckweed belongs to the sea, where not to meet in life
>
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

OK, please do something with your client. Having the footer here on top
for every reply is *so* bothersome when you are replying inline
(that part is fine).


Sorry, I removed footer, better now?



Way better, thank you very much.  I always didn't know whether to look
for the rest of the message or not.  And as you can see, after some
replies, it's hard to read what was discussed:



> On Wednesday, 29 March 2017 at 5:19 PM, Martin Kletzander wrote:
>
> > On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:
> > >
> > >
> > > --
> > > Best regards
> > > Eli
> > >
> > > 天涯无处不重逢
> > > a leaf duckweed belongs to the sea, where not to meet in life
> > >
> > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> > >
> > >
> > > On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:
> > >
> > > > On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:



Look hoe much space it took ^^, and that's only once in there ;)


> > > > > hi Martin
> > > > >
> > > > > (cc libvir-list)
> > > > >
> > > > > I am a little confused about cat support.
> > > > >
> > > > > I am currently rebasing my code on top of pre-cat branch from your 
private github repo, today when I check it you have removed it and create a cat branch and 
there are some related code pushed[1], can I know what ’s your plan for my patch set for CAT 
support ? should I continue my rebasing work? your though?
> > > >
> > > > So we can work together on that. Since the rework of the sysfs
> > > > functions, some patches are easier to write from scratch then rewrite,
> > > > but I'm now just trying to setup the test suite, so that we have
> > > > something to test on, at least some of the code. So where are you in
> > > > the rebase right now? Do you think anything from the virsysfs.c code
> > > > could be enhanced?
> > > >
> > >
> > >
> > >
> > >
> > >
> > > Not so fast, only the first patch [1], I found that nodeinfo.c is removed 
:(
> > >
> > > I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint 
to virsysfs.c
> > >
> > > thought ?
> >
> > Yeah, we should wrap around /sys/fs/resctrl as we do with
> > /sys/devices/system so that it can be easily tested.
> >
>
> Sure, working on it, and done, will push it for review.
>
> Also I will push some fake data for resctrl testing..
>
>
> >
> > Also I got another idea about keeping the resource info. There is no
> > need for any global data to be stored as you are re-reading almost all
> > of it. The only info that stays the same is caches (that is already
> > saved in capabilities) and what caches are available for resource
> > control (that will be there as well). So I don't think we need yet
> > another global data storage.
> >
>
>
> Do you mean, we re-create all struct (reading them from /sys/fs/resctrl) when 
we create/destroy instance?
> also, for get free cache ?
>


You have to update that for every request anyway, so what's the point of
keeping the data when they immediately become old?


I was thought that may reduce the time costing, not all of the content be 
refreshed, anyway, I will try to avoid global files in my later version.



Well, if there is something that does not need refreshing, then you
might consider adding it to capabilities (if it is helpful to the user
in any way).


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] test: Add fake cpu id file

2017-03-29 Thread Martin Kletzander


On Wed, Mar 29, 2017 at 05:50:05PM +0800, Eli Qiao wrote:

Added fake cpu cache id and resctrl file



Thanks for that, however I would rather see you adding new directory to
tests/vircaps2xmldata which describes yet another machine, so that we
have different inputs to the tests.

I have the ID files ready to be added in my series and the tests are now
passing fine (I'll send it upstream after release, it's pointless now
since it won't go it before the release anyway).

I'll push it to the cat branch on github today after I clean up the commits.


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [GSoC] Libvirt accepted as GSoC 2017 mentor organization

2017-03-29 Thread Michal Privoznik


On 02/28/2017 01:11 PM, Michal Privoznik wrote:

Dear all,

yesterday I received great news: Libvirt has been accepted as a mentor
organization for this year's Google Summer of Code [1].



Just a gentle reminder that students application deadline is April 3rd 
16:00 UTC so if you are a student and wish to participate now is the 
right time to submit your application.


Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] news: Make changes understandable for users

2017-03-29 Thread John Ferlan

On 03/29/2017 03:54 AM, Andrea Bolognani wrote:
> On Tue, 2017-03-28 at 22:17 +0200, Martin Kletzander wrote:
>>> This one looks like it would qualify on several accounts,
>>> but it could also definitely use a description to flesh out
>>> exactly what was changed, something along the lines of
>>>  
>>>
>>>  Initialize volumes properly when building LVM storage pools
>>>
>>>
>>>  Volumes containing filesystem signatures need to have it
>>>  wiped out before they can be used in an LVM storage pools.
>>>  libvirt was unable to wipe out the signature for some
>>>  filesystem (such as ext4) but that limitation has now been
>>>  addressed.
>>>
>>  
>> Yeah, that's almost perfect (s/an LVM/LVM/), but I understand that not
>> everyone wants to come up with such description.  It would not have to
>> be if it was similarly worded in the commit message.
> 
> I'll be honest: it took me several passes (and several
> minutes) to come up with that text, so I can see quite
> clearly how not everyone would be willing to spend the
> same amount of time and effort on release notes.
> 

I find it ironic that I went against my normal practice and tried not to
be verbose. Just copying the git commit id message for a one liner. And
now it's turning into a more lengthy description.

Another "thought" here would be that "bugs" would be required to list
their bz in the description section and the summary would be just the
"short" (e.g. < 72 chars) git commit message. Leaving the 'details' in
the bug for anyone that cared about "logical" storage pools to go read.
Thus, for this one would have:

logical: Need to overwrite/clear more than just first 512 bytes

https://bugzilla.redhat.com/show_bug.cgi?id=1430679

(oh and yes, I could have written a better commit id message, I did try,
but kept running too long).

Or instead of  it could be #> Anyway, I guess I'm just overreacting to some of these changes.  I'm
>> sorry for that.  I just feel like we went out of our ways to make
>> something nicer for the users out there, and start falling back into the
>> old tracks not long after it.  I compare it to git's release notes [1]
>> which I always find a) very understandable and b) to the point
>> (i.e. brief, no fuzzing around, but also missing only information you
>> can easily find out yourself, e.g. in a man page), but I don't know why
>> I'm so touchy regarding this subject.
> 
> Git's release notes have clearly been written and edited
> by a single individual, so of course they're going to be
> more consistent in tone and style than whatever our fairly
> large community of contributors can come up with over the
> span of a release.

Release notes are kind of an "organic process" and should be tailored to
the needs of each product with the consumer of the release notes in
mind. Not everyone that uses libvirt keeps "up to date" with the daily
patches and knows (more or less) exactly what's going on.

What we're doing now is a lot better than having DV sorting the various
commit id messages into groups. I'm sure this has made release
generation a bit easier for him!

We need to find that "happy medium" of providing enough information
without overloading. I actually think we're doing pretty good at that
right now. We may have missed a few things along the way, but it's
become part of a review and check-in process relatively quickly. It's
not perfect and definitely won't please everyone's idea of aesthetics.

John

> 
> My original intention was to be more active on this front
> and provide more oversight, including editing entries
> outright if necessary. I have unfortunately failed to do
> a very good job so far, and I apologize for that.
> 
> But I wouldn't say all hope is lost: for starters, I'll
> try to find some time to improve the release notes for
> the current release before the end of the freeze. And
> since you seem to be taking interest in the issue, maybe
> we can both try to work on it on an ongoing basis? :)
> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Eli Qiao



On Wednesday, 29 March 2017 at 5:47 PM, Martin Kletzander wrote:

> On Wed, Mar 29, 2017 at 05:31:42PM +0800, Eli Qiao wrote:
> >  
> >  
> > --
> > Best regards
> > Eli
> >  
> > 天涯无处不重逢
> > a leaf duckweed belongs to the sea, where not to meet in life
> >  
> > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>  
> OK, please do something with your client. Having the footer here on top
> for every reply is *so* bothersome when you are replying inline
> (that part is fine).
>  
Sorry, I removed footer, better now?
  
>  
> > On Wednesday, 29 March 2017 at 5:19 PM, Martin Kletzander wrote:
> >  
> > > On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:
> > > >  
> > > >  
> > > > --
> > > > Best regards
> > > > Eli
> > > >  
> > > > 天涯无处不重逢
> > > > a leaf duckweed belongs to the sea, where not to meet in life
> > > >  
> > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> > > >  
> > > >  
> > > > On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:
> > > >  
> > > > > On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:
> > > > > > hi Martin
> > > > > >  
> > > > > > (cc libvir-list)
> > > > > >  
> > > > > > I am a little confused about cat support.
> > > > > >  
> > > > > > I am currently rebasing my code on top of pre-cat branch from your 
> > > > > > private github repo, today when I check it you have removed it and 
> > > > > > create a cat branch and there are some related code pushed[1], can 
> > > > > > I know what ’s your plan for my patch set for CAT support ? should 
> > > > > > I continue my rebasing work? your though?
> > > > >  
> > > > > So we can work together on that. Since the rework of the sysfs
> > > > > functions, some patches are easier to write from scratch then rewrite,
> > > > > but I'm now just trying to setup the test suite, so that we have
> > > > > something to test on, at least some of the code. So where are you in
> > > > > the rebase right now? Do you think anything from the virsysfs.c code
> > > > > could be enhanced?
> > > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > Not so fast, only the first patch [1], I found that nodeinfo.c is 
> > > > removed :(
> > > >  
> > > > I think we need to extend virResCtrlGetInfoStr and 
> > > > virResCtrlGetInfoUint to virsysfs.c
> > > >  
> > > > thought ?
> > >  
> > > Yeah, we should wrap around /sys/fs/resctrl as we do with
> > > /sys/devices/system so that it can be easily tested.
> > >  
> >  
> > Sure, working on it, and done, will push it for review.
> >  
> > Also I will push some fake data for resctrl testing..
> >  
> >  
> > >  
> > > Also I got another idea about keeping the resource info. There is no
> > > need for any global data to be stored as you are re-reading almost all
> > > of it. The only info that stays the same is caches (that is already
> > > saved in capabilities) and what caches are available for resource
> > > control (that will be there as well). So I don't think we need yet
> > > another global data storage.
> > >  
> >  
> >  
> > Do you mean, we re-create all struct (reading them from /sys/fs/resctrl) 
> > when we create/destroy instance?
> > also, for get free cache ?
> >  
>  
>  
> You have to update that for every request anyway, so what's the point of
> keeping the data when they immediately become old?
>  
I was thought that may reduce the time costing, not all of the content be 
refreshed, anyway, I will try to avoid global files in my later version.  

LoL lots of rebasing  :(  

Thanks for your suggestion.
>  
> > This is what I did in my early PoC, that will much easier… but please keep 
> > in mind that only one thread can read/write to /sys/fs/resctrl at one time.
>  
>  
> Yeah, that's what we have locks for.
>  
> > the neck bottle is /sys/fs/resctrl
>  
> Sure you mean bottleneck, right? :)
yes, bottleneck,  

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] test: Add fake cpu id file

2017-03-29 Thread Eli Qiao

Added fake cpu cache id and resctrl file

Signed-off-by: Eli Qiao 
---
 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index0/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index1/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index2/id | 1 +
 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index3/id | 1 +
 tests/vircaps2xmldata/linux-resctrl/cpus| 1 +
 tests/vircaps2xmldata/linux-resctrl/info/L3/cbm_mask| 1 +
 tests/vircaps2xmldata/linux-resctrl/info/L3/min_cbm_bits| 1 +
 tests/vircaps2xmldata/linux-resctrl/info/L3/num_closids | 1 +
 tests/vircaps2xmldata/linux-resctrl/schemata| 1 +
 tests/vircaps2xmldata/linux-resctrl/tasks   | 2 ++
 38 files changed, 39 insertions(+)
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index0/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index1/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index2/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index3/id
 create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index0/id
 create mode 100644 tests

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Martin Kletzander

On Wed, Mar 29, 2017 at 05:31:42PM +0800, Eli Qiao wrote:

--
Best regards
Eli

天涯无处不重逢
a leaf duckweed belongs to the sea, where not to meet in life

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

OK, please do something with your client.  Having the footer here on top
for every reply is *so* bothersome when you are replying inline
(that part is fine).

On Wednesday, 29 March 2017 at 5:19 PM, Martin Kletzander wrote:

On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:
>
>
> --
> Best regards
> Eli
>
> 天涯无处不重逢
> a leaf duckweed belongs to the sea, where not to meet in life
>
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>
>
> On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:
>
> > On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:
> > > hi Martin
> > >
> > > (cc libvir-list)
> > >
> > > I am a little confused about cat support.
> > >
> > > I am currently rebasing my code on top of pre-cat branch from your 
private github repo, today when I check it you have removed it and create a cat branch 
and there are some related code pushed[1], can I know what ’s your plan for my patch set 
for CAT support ? should I continue my rebasing work? your though?
> >
> > So we can work together on that. Since the rework of the sysfs
> > functions, some patches are easier to write from scratch then rewrite,
> > but I'm now just trying to setup the test suite, so that we have
> > something to test on, at least some of the code. So where are you in
> > the rebase right now? Do you think anything from the virsysfs.c code
> > could be enhanced?
> >
>
>
>
>
> Not so fast, only the first patch [1], I found that nodeinfo.c is removed :(
>
> I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint to 
virsysfs.c
>
> thought ?

Yeah, we should wrap around /sys/fs/resctrl as we do with
/sys/devices/system so that it can be easily tested.

Sure, working on it, and done, will push it for review.

Also I will push some fake data for resctrl testing..

Also I got another idea about keeping the resource info. There is no
need for any global data to be stored as you are re-reading almost all
of it. The only info that stays the same is caches (that is already
saved in capabilities) and what caches are available for resource
control (that will be there as well). So I don't think we need yet
another global data storage.

Do you mean, we re-create all struct (reading them from /sys/fs/resctrl) when 
we create/destroy instance?
also, for get free cache ?

You have to update that for every request anyway, so what's the point of
keeping the data when they immediately become old?

This is what I did in my early PoC, that will much easier… but please keep in 
mind that only one thread can read/write to /sys/fs/resctrl at one time.

Yeah, that's what we have locks for.

the neck bottle is /sys/fs/resctrl

Sure you mean bottleneck, right? :)

signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] encountered failed test cases with latest checkout of libvirt

2017-03-29 Thread Michal Privoznik


On 03/29/2017 09:01 AM, Dan wrote:

On Wed, Mar 29, 2017 at 1:01 AM, D L  wrote:


Hi all,

This email content might be duplicated with other thread posted in other
places that I do not know yet where to find or search (please let me know
if it is true). I am working on a small bug of virsh domxml-to-native.
Before I made any changes to the code in order to fix the bug, I 'make
 test'-ed and 'valgrind test'-ed the code, encountered four failures in
'make test' and 19 failures in 'make -C tests valgrind'. What I did today
was the following:

git checkout master
git pull
./autogen.sh --prefix=$(pwd)/build
make
make install
# So far so good, no errors ; however

make check VIR_TEST_EXPENSIVE=1
# generated the following test-suite.log
=
   libvirt 3.2.0: tests/test-suite.log
=

# TOTAL: 115
# PASS:  111
# SKIP:  0
# XFAIL: 0
# FAIL:  4
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: virfirewalltest
=

TEST: virfirewalltest
   40  FAIL
FAIL virfirewalltest (exit status: 1)

FAIL: networkxml2firewalltest
=

TEST: networkxml2firewalltest
 0   FAIL
FAIL networkxml2firewalltest (exit status: 1)

FAIL: nwfilterebiptablestest


TEST: nwfilterebiptablestest
 0   FAIL
FAIL nwfilterebiptablestest (exit status: 1)

FAIL: nwfilterxml2firewalltest
==

TEST: nwfilterxml2firewalltest
 0   FAIL
FAIL nwfilterxml2firewalltest (exit status: 1)



make syntax-check VIR_TEST_EXTENSIVE=1
# I did not paste the result here and I do not understand what it means.
# available upon request

Finally,
make -C tests valgrind
# generated file was attached.

It seems most of the valgrind failures were false positives, I can only
tell
by comparing the log file with the examples in the HACKING page. But I
do not have the knowledge to determine.

Could anyone tell me if I am missing something? Having those test failures
is a problem or not? Which ones can be safely ignored? Is there any easier
way to avoid the false positives? I am concerned because I also need to
run the test when I make changes to the code. On the other hand, I would
also like to learn the right way to do the testing or whatever it takes to
make
things right.

I am running linux using vmware Workstation Pro 12 on Windows 10.
Linux version 4.4.55-1-MANJARO (builduser@manjaro) (gcc version 6.3.1
20170306 (GCC) ) #1 SMP PREEMPT



Dan



On ubuntu16 and ubuntu14, ebtables were pre-installed. But on

Archlinux and Debian, ebtables have to be installed explicitly in order to
pass
all test cases in 'make check'.  I found out this after I enabled debugging
checking
$ make check VIR_TEST_DEBUG=2 VIR_TEST_EXPENSIVE=1


Ah, very well you. I'm not sure what to do here. I mean, we should 
definitely skip networkxml2firewalltest, nwfilterebiptablestest and 
nwfilterxml2firewalltest if EBTABLES is undefined. But the first one is 
slightly more tricky as it can use DBUS when available. Well, we can 
skip it it neither of DBUS and EBTABLES is present. This can be your 
first patch to libvirt ;-)




For the valgrind testing with 'make -C tests valgrind', the errors were
*mostly* due to
"FATAL: can't open suppressions file "./.valgrind.supp". I am using
valgrind 3.12.0.



That's weird, the file should be there. What is a problem though is our 
mocking. Due to some weird glibc-ness, valgrind cannot handle libraries 
that have some unresolved symbols. For instance, if library L that is 
loaded from binary B provides symbols L1 and L2 but rely on symbol B1, 
valgrind (in fact glibc) fails to load the binary even though if run 
without valgrind everything works just fine.


I've looked into this the other day and went from our sources to 
valgrind ones and from there to glibc where I got lost. For instance, 
virpcitest fails because virpcimock uses virAlloc, virFree and other 
internal APIs even though it's not linking with libvirt_util.


Frankly, I've no idea how to fix this. Perhaps Eric have a bright idea?
BTW: linking the mock with libvirt_util fails in exactly the opposite 
case - when not running under valgrind.


Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] util: Add more virsysfs functions for handling resctrl sysfs

2017-03-29 Thread Eli Qiao

Extended /sys/fs/resctrl sysfs handling.

Signed-off-by: Eli Qiao 
---
 src/libvirt_private.syms |  4 ++
 src/util/virsysfs.c  | 98 +++-
 src/util/virsysfs.h  | 15 
 3 files changed, 116 insertions(+), 1 deletion(-)

diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index b551cb8..e07ae79 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2631,6 +2631,10 @@ virSysfsGetValueBitmap;
 virSysfsGetValueInt;
 virSysfsGetValueString;
 virSysfsSetSystemPath;
+virSysfsGetResctrlString;
+virSysfsGetResctrlUint;
+virSysfsGetResctrlInfoString;
+virSysfsGetResCtrInfoUint;
 
 
 # util/virsysinfo.h
diff --git a/src/util/virsysfs.c b/src/util/virsysfs.c
index 7a98b48..d1be289 100644
--- a/src/util/virsysfs.c
+++ b/src/util/virsysfs.c
@@ -36,8 +36,10 @@ VIR_LOG_INIT("util.sysfs");
 
 #define VIR_SYSFS_VALUE_MAXLEN 8192
 #define SYSFS_SYSTEM_PATH "/sys/devices/system"
+#define SYSFS_RESCTRL_PATH "/sys/fs/resctrl"
 
 static const char *sysfs_system_path = SYSFS_SYSTEM_PATH;
+static const char *sysfs_resctrl_path = SYSFS_RESCTRL_PATH;
 
 
 void virSysfsSetSystemPath(const char *path)
@@ -48,13 +50,26 @@ void virSysfsSetSystemPath(const char *path)
 sysfs_system_path = SYSFS_SYSTEM_PATH;
 }
 
-
 const char *
 virSysfsGetSystemPath(void)
 {
 return sysfs_system_path;
 }
 
+void virSysfsSetResctrlPath(const char *path)
+{
+if (path)
+sysfs_resctrl_path  = path;
+else
+sysfs_resctrl_path = SYSFS_RESCTRL_PATH;
+}
+
+const char *
+virSysfsGetResctrlPath(void)
+{
+return sysfs_resctrl_path;
+}
+
 int
 virSysfsGetValueInt(const char *file,
 int *value)
@@ -227,3 +242,84 @@ virSysfsGetNodeValueBitmap(unsigned int node,
 VIR_FREE(path);
 return ret;
 }
+
+int
+virSysfsGetResctrlString(const char* file,
+ char **value)
+{
+chat *path = NULL;
+int ret = -1;
+if (virAsprintf(&path, "%s/%s", sysfs_resctrl_path, file) < 0)
+if (!virFileExists(path)) {
+ret = -2;
+goto cleanup;
+}
+
+if (virFileReadAll(path, VIR_SYSFS_VALUE_MAXLEN, value) < 0)
+goto cleanup;
+
+ret = 0;
+
+ cleanup:
+VIR_FREE(path);
+return ret;
+}
+
+int
+virSysfsGetResctrlUint(const char* file,
+   unsigned int **value)
+{
+chat *path = NULL;
+int ret = -1;
+if (virAsprintf(&path, "%s/%s", sysfs_resctrl_path, file) < 0)
+if (!virFileExists(path)) {
+ret = -2;
+goto cleanup;
+}
+
+ret = virFileReadValueUint(path, value);
+
+ cleanup:
+VIR_FREE(path);
+return ret;
+}
+
+int
+virSysfsGetResctrlInfoString(const char* file,
+ char **value)
+{
+chat *path = NULL;
+int ret = -1;
+if (virAsprintf(&path, "%s/info/%s", sysfs_resctrl_path, file) < 0)
+return -1;
+
+if (!virFileExists(path)) {
+ret = -2;
+goto cleanup;
+}
+
+if (virFileReadAll(path, VIR_SYSFS_VALUE_MAXLEN, value) < 0)
+goto cleanup;
+
+ret = 0;
+
+ cleanup:
+VIR_FREE(path);
+return ret;
+}
+
+int
+virSysfsGetResCtrInfoUint(const char *file,
+  unsigned int *value)
+{
+char *path = NULL;
+int ret = -1;
+
+if (virAsprintf(&path, "%s/info/%s", sysfs_resctrl_path, file) < 0)
+return -1;
+
+ret = virFileReadValueUint(path, value);
+
+VIR_FREE(path);
+return ret;
+}
diff --git a/src/util/virsysfs.h b/src/util/virsysfs.h
index cd871ff..81a27c2 100644
--- a/src/util/virsysfs.h
+++ b/src/util/virsysfs.h
@@ -67,4 +67,19 @@ virSysfsGetNodeValueBitmap(unsigned int cpu,
const char *file,
virBitmapPtr *value);
 
+int
+virSysfsGetResctrlString(const char* file,
+ char **value);
+
+int
+virSysfsGetResctrlUint(const char* file,
+   unsigned int **value);
+
+int
+virSysfsGetResctrlInfoString(const char* file,
+ char **value);
+
+int
+virSysfsGetResCtrInfoUint(const char *file,
+  unsigned int *value);
 #endif /* __VIR_SYSFS_H__*/
-- 
1.9.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] encountered failed test cases with latest checkout of libvirt

2017-03-29 Thread Martin Kletzander


On Wed, Mar 29, 2017 at 03:01:06AM -0400, Dan wrote:

For the valgrind testing with 'make -C tests valgrind', the errors were
*mostly* due to
"FATAL: can't open suppressions file "./.valgrind.supp". I am using
valgrind 3.12.0.



Yeah, we reference the suppression file relatively, you need to:

 cd tests
 make valgrind

instead the -C parameter.


Dan



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Eli Qiao



--  
Best regards  
Eli

天涯无处不重逢
a leaf duckweed belongs to the sea, where not to meet in life  

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Wednesday, 29 March 2017 at 5:19 PM, Martin Kletzander wrote:

> On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:
> >  
> >  
> > --
> > Best regards
> > Eli
> >  
> > 天涯无处不重逢
> > a leaf duckweed belongs to the sea, where not to meet in life
> >  
> > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> >  
> >  
> > On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:
> >  
> > > On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:
> > > > hi Martin
> > > >  
> > > > (cc libvir-list)
> > > >  
> > > > I am a little confused about cat support.
> > > >  
> > > > I am currently rebasing my code on top of pre-cat branch from your 
> > > > private github repo, today when I check it you have removed it and 
> > > > create a cat branch and there are some related code pushed[1], can I 
> > > > know what ’s your plan for my patch set for CAT support ? should I 
> > > > continue my rebasing work? your though?
> > >  
> > > So we can work together on that. Since the rework of the sysfs
> > > functions, some patches are easier to write from scratch then rewrite,
> > > but I'm now just trying to setup the test suite, so that we have
> > > something to test on, at least some of the code. So where are you in
> > > the rebase right now? Do you think anything from the virsysfs.c code
> > > could be enhanced?
> > >  
> >  
> >  
> >  
> >  
> > Not so fast, only the first patch [1], I found that nodeinfo.c is removed :(
> >  
> > I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint to 
> > virsysfs.c
> >  
> > thought ?
>  
> Yeah, we should wrap around /sys/fs/resctrl as we do with
> /sys/devices/system so that it can be easily tested.
>  
Sure, working on it, and done, will push it for review.

Also I will push some fake data for resctrl testing..
  
  
>  
> Also I got another idea about keeping the resource info. There is no
> need for any global data to be stored as you are re-reading almost all
> of it. The only info that stays the same is caches (that is already
> saved in capabilities) and what caches are available for resource
> control (that will be there as well). So I don't think we need yet
> another global data storage.
>  
>  

Do you mean, we re-create all struct (reading them from /sys/fs/resctrl) when 
we create/destroy instance?  
also, for get free cache ?

This is what I did in my early PoC, that will much easier… but please keep in 
mind that only one thread can read/write to /sys/fs/resctrl at one time.

the neck bottle is /sys/fs/resctrl
  
>   
>  
>  


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] libvirt3.1.0 bug suspected: libvirtd restart, VM start/stop

2017-03-29 Thread Michal Privoznik


On 03/28/2017 01:54 PM, Stepan Andr wrote:

Hi all,

It seems there is a bug for libvirtd which I couldn't find here

.

*Here is description:*
Version-Release number of selected component (if applicable):
Libvirt - 3.1.0 (built from tarball)

How reproducible:
100%

Precondition: libvirtd running. One VM is running, other(s) are 'shut off'.
Steps to Reproduce:
1. Stop libvirtd while VM#1 is running.
2. Start libvirtd (VM#1 is running).
3. Stop VM#1. Verify if VM#1 is present in the list of all VM's ('virsh
list --all').
4. Start VM#1. Verify if VM#1 is present in the list of all VM's ('virsh
list --all').
5. Go to step #3. Note: Steps may be needed to repeat two times.

Recover action:
 restart libvirtd service (service libvirtd restart/systemctl restart
libvirtd).

Actual results:
 #3. VM#1 disappears from the list of all VM's.

Expected results:
 #3. VM#1 should be present in the list of all VM's.



I'm unable to reproduce this behaviour. Can you:

a) share the domain XML with us?
b) provide daemon debug logs [1]?
c) check that all the uuids for your domains are unique?


1: http://wiki.libvirt.org/page/DebugLogs

BTW: Feel free to open a new bug and attach those informations there. 
Bugzilla is where bugs are tracked anyway.


Thanks,
Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Martin Kletzander

On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:

--
Best regards
Eli

天涯无处不重逢
a leaf duckweed belongs to the sea, where not to meet in life

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:

On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:
> hi Martin
>
> (cc libvir-list)
>
> I am a little confused about cat support.
>
> I am currently rebasing my code on top of pre-cat branch from your private 
github repo, today when I check it you have removed it and create a cat branch and 
there are some related code pushed[1], can I know what ’s your plan for my patch 
set for CAT support ? should I continue my rebasing work? your though?

So we can work together on that. Since the rework of the sysfs
functions, some patches are easier to write from scratch then rewrite,
but I'm now just trying to setup the test suite, so that we have
something to test on, at least some of the code. So where are you in
the rebase right now? Do you think anything from the virsysfs.c code
could be enhanced?

Not so fast, only the first patch [1], I found that nodeinfo.c is removed :(

I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint to 
virsysfs.c

thought ?

Yeah, we should wrap around /sys/fs/resctrl as we do with
/sys/devices/system so that it can be easily tested.

Also I got another idea about keeping the resource info.  There is no
need for any global data to be stored as you are re-reading almost all
of it.  The only info that stays the same is caches (that is already
saved in capabilities) and what caches are available for resource
control (that will be there as well).  So I don't think we need yet
another global data storage.

signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 11/14] qemu: Bump the memory locking limit for mdevs as well

2017-03-29 Thread Erik Skultety

On Wed, Mar 29, 2017 at 10:41:52AM +0200, Andrea Bolognani wrote:
> On Wed, 2017-03-22 at 16:27 +0100, Erik Skultety wrote:
> > Since mdevs are just another type of VFIO devices, we should increase
> > the memory locking limit the same way we do for VFIO PCI devices.
> >
> > Signed-off-by: Erik Skultety 
> > ---
> >  src/qemu/qemu_domain.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index d1ac1d641b..04e64b47ea 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -6347,11 +6347,12 @@ qemuDomainRequiresMemLock(virDomainDefPtr def)
> >  return true;
> >
> >  for (i = 0; i < def->nhostdevs; i++) {
> > -virDomainHostdevDefPtr dev = def->hostdevs[i];
> > +virDomainHostdevSubsysPtr subsys = 
> > &def->hostdevs[i]->source.subsys;
> >
> > -if (dev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > -dev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI 
> > &&
> > -dev->source.subsys.u.pci.backend == 
> > VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
> > +if (def->hostdevs[i]->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > +(subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV ||
> > + (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> > +  subsys->u.pci.backend == 
> > VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)))
> >  return true;
> >  }
>
> Now that we have test suite coverage for the calculation of
> memory locking limits (qemumemlocktest), it would be neat
> if you could add test cases for mdevs as well.

I'll look into that, thanks for raising this up.

>
> Maybe the comment above the loop (which has been moved to
> the qemuDomainGetMemLockLimitBytes() function now) could be
> updated to mention mdev-specific information, if any?
>

None that I'm aware of at the moment, but I'll discuss this with Alex just to be
sure.

Erik

> --
> Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 11/14] qemu: Bump the memory locking limit for mdevs as well

2017-03-29 Thread Andrea Bolognani

On Wed, 2017-03-22 at 16:27 +0100, Erik Skultety wrote:
> Since mdevs are just another type of VFIO devices, we should increase
> the memory locking limit the same way we do for VFIO PCI devices.
> 
> Signed-off-by: Erik Skultety 
> ---
>  src/qemu/qemu_domain.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index d1ac1d641b..04e64b47ea 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -6347,11 +6347,12 @@ qemuDomainRequiresMemLock(virDomainDefPtr def)
>  return true;
>  
>  for (i = 0; i < def->nhostdevs; i++) {
> -virDomainHostdevDefPtr dev = def->hostdevs[i];
> +virDomainHostdevSubsysPtr subsys = &def->hostdevs[i]->source.subsys;
>  
> -if (dev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> -dev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> -dev->source.subsys.u.pci.backend == 
> VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
> +if (def->hostdevs[i]->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> +(subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV ||
> + (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> +  subsys->u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)))
>  return true;
>  }

Now that we have test suite coverage for the calculation of
memory locking limits (qemumemlocktest), it would be neat
if you could add test cases for mdevs as well.

Maybe the comment above the loop (which has been moved to
the qemuDomainGetMemLockLimitBytes() function now) could be
updated to mention mdev-specific information, if any?

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Eli Qiao



--  
Best regards  
Eli

天涯无处不重逢
a leaf duckweed belongs to the sea, where not to meet in life  

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:

> On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:
> > hi Martin
> >  
> > (cc libvir-list)
> >  
> > I am a little confused about cat support.
> >  
> > I am currently rebasing my code on top of pre-cat branch from your private 
> > github repo, today when I check it you have removed it and create a cat 
> > branch and there are some related code pushed[1], can I know what ’s your 
> > plan for my patch set for CAT support ? should I continue my rebasing work? 
> > your though?
>  
> So we can work together on that. Since the rework of the sysfs
> functions, some patches are easier to write from scratch then rewrite,
> but I'm now just trying to setup the test suite, so that we have
> something to test on, at least some of the code. So where are you in
> the rebase right now? Do you think anything from the virsysfs.c code
> could be enhanced?
>  
>  



Not so fast, only the first patch [1], I found that nodeinfo.c is removed :(  

I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint to 
virsysfs.c

thought ?

[1]https://github.com/taget/libvirt/commits/cdp_v11
  
>  
> > [1] 
> > https://github.com/nertpinx/libvirt/commit/c335de47a4efeca87f23e641a93587b1e036e558
> >  
> > Thanks Eli.
> >  
> >  
> >  
> > --
> > Best regards
> > Eli
> >  
> > 天涯无处不重逢
> > a leaf duckweed belongs to the sea, where not to meet in life
> >  
> > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> >  
> >  
> > On Friday, 24 March 2017 at 3:42 PM, Martin Kletzander wrote:
> >  
> > > On Fri, Mar 24, 2017 at 09:35:33AM +0800, Eli Qiao wrote:
> > > >  
> > > >  
> > > > --
> > > > Best regards
> > > > Eli
> > > >  
> > > > 天涯无处不重逢
> > > > a leaf duckweed belongs to the sea, where not to meet in life
> > > >  
> > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> > > >  
> > > >  
> > > > On Thursday, 16 March 2017 at 3:52 PM, Eli Qiao wrote:
> > > >  
> > > > >  
> > > > >  
> > > > > --
> > > > > Best regards
> > > > > Eli
> > > > >  
> > > > > 天涯无处不重逢
> > > > > a leaf duckweed belongs to the sea, where not to meet in life
> > > > >  
> > > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> > > > >  
> > > > >  
> > > > > On Wednesday, 15 March 2017 at 7:57 PM, Martin Kletzander wrote:
> > > > >  
> > > > > > On Mon, Mar 06, 2017 at 06:06:30PM +0800, Eli Qiao wrote:
> > > > > > > This patch adds some utils struct and functions to expose resctrl
> > > > > > > information.
> > > > > > >  
> > > > > > > virResCtrlAvailable: if resctrl interface exist on host.
> > > > > > > virResCtrlGet: get specific type resource control information.
> > > > > > > virResCtrlInit: initialize resctrl struct from the host's sys fs.
> > > > > > > resctrlall[]: an array to maintain resource control information.
> > > > > > >  
> > > > > > > Some of host cpu related information methods was added in 
> > > > > > > virhostcpu.c
> > > > > >  
> > > > > > So to be able to test all this we need to make a bit different 
> > > > > > approach.
> > > > > > I'm not in favour of pushing this without proper tests. Some paths 
> > > > > > need
> > > > > > to be configurable, some readings should be unified. Unfortunately 
> > > > > > lot
> > > > > > of the code is just copy-paste mess from the past. Fortunately for 
> > > > > > you,
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > I'm working on cleaning this up, at least a little bit, so that we 
> > > > > > can
> > > > >  
> > > > > Good news.
> > > > > > add the tests easily. I got almost up to the test (I stumbled upon 
> > > > > > few
> > > > > > rabbit holes on the way and some clean-ups went wrong along the 
> > > > > > way), so
> > > > > > it should be pretty easy for you to modify this code to use what 
> > > > > > I'll be
> > > > > > proposing to add. It's not ready yet, but you can start rebasing 
> > > > > > your
> > > > > > series on top of my branch pre-cat from my github repo [1]. The 
> > > > > > commits
> > > > > > are not very well described right now (for some temporary ones I 
> > > > > > used
> > > > > > whatthecommit.com (http://whatthecommit.com), sorry), but I'll fix 
> > > > > > all that. I'll be updating the
> > > > > > branch, but it will be done with force pushes, so be careful when
> > > > > > rebasing on top of newer versions.
> > > > > >  
> > > > > > I can do that if you don't want, just let me know so we can 
> > > > > > coordinate.
> > > > > of cause we can do some coordinate, but I am glad that you can help 
> > > > > on this to speed up the progress to merge them, as you know this 
> > > > > patch is in V10 already, and it has 12 patch set, kinds of hard to 
> > > > > doing rebase… :(
> > > > >  
> > > > >  
> > > > > > Just a quick heads-up, there will be virsysfs that will be used for 
> > > > > > t

[libvirt] [PATCH] [libvirt-php] allow to specify empty base and top

2017-03-29 Thread Vasiliy Tolstov

allow to specify empty base and top to do active block commit

Vasiliy Tolstov (1):
  allow to specify empty base and top for block commit

 src/libvirt-php.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] allow to specify empty base and top for block commit

2017-03-29 Thread Vasiliy Tolstov

Signed-off-by: Vasiliy Tolstov 
---
 src/libvirt-php.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/src/libvirt-php.c b/src/libvirt-php.c
index e8384795d635..6bbacda19611 100644
--- a/src/libvirt-php.c
+++ b/src/libvirt-php.c
@@ -313,7 +313,7 @@ ZEND_ARG_INFO(0, memory)
 ZEND_ARG_INFO(0, flags)
 ZEND_END_ARG_INFO()
 
-ZEND_BEGIN_ARG_INFO_EX(arginfo_libvirt_domain_block_commit, 0, 0, 3)
+ZEND_BEGIN_ARG_INFO_EX(arginfo_libvirt_domain_block_commit, 0, 0, 2)
 ZEND_ARG_INFO(0, res)
 ZEND_ARG_INFO(0, disk)
 ZEND_ARG_INFO(0, base)
@@ -6986,16 +6986,22 @@ PHP_FUNCTION(libvirt_domain_block_commit)
 php_libvirt_domain *domain = NULL;
 zval *zdomain;
 int retval;
-char *disk;
-int disk_len;
+char *disk = NULL;
+strsize_t disk_len;
 char *base = NULL;
-int base_len;
+strsize_t base_len;
 char *top = NULL;
-int top_len;
-long bandwidth = 0;
-long flags = 0;
+strsize_t top_len;
+zend_long bandwidth = 0;
+zend_long flags = 0;
 
-GET_DOMAIN_FROM_ARGS("rsssll", &zdomain, &disk, &disk_len, &base, 
&base_len, &top, &top_len, &bandwidth, &flags);
+GET_DOMAIN_FROM_ARGS("rs|ssll", &zdomain, &disk, &disk_len, &base, 
&base_len, &top, &top_len, &bandwidth, &flags);
+if (strcmp(disk, "") == 0)
+RETURN_FALSE;
+if (strcmp(base, "") == 0)
+base = NULL;
+if (strcmp(top, "") == 0)
+top = NULL;
 
 retval = virDomainBlockCommit(domain->domain, disk, base, top, bandwidth, 
flags);
 if (retval == -1)
-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] network: Drop unused networkRestartRadvd

2017-03-29 Thread Michal Privoznik

Since its introduction in 1ce4922e720 this function lived as an
outcast in an #if 0 block.

Signed-off-by: Michal Privoznik 
---
 src/network/bridge_driver.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 5ccd37a..ddd2a3a 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -1980,33 +1980,6 @@ networkRefreshRadvd(virNetworkDriverStatePtr driver,
 return kill(network->radvdPid, SIGHUP);
 }
 
-#if 0
-/* currently unused, so it causes a build error unless we #if it out */
-static int
-networkRestartRadvd(virNetworkObjPtr network)
-{
-char *radvdpidbase;
-
-/* if there is a running radvd, kill it */
-if (network->radvdPid > 0) {
-/* essentially ignore errors from the following two functions,
- * since there's really no better recovery to be done than to
- * just push ahead (and that may be exactly what's needed).
- */
-if ((networkKillDaemon(network->radvdPid, "radvd",
-   network->def->name) >= 0) &&
-((radvdpidbase = networkRadvdPidfileBasename(network->def->name))
- != NULL)) {
-virPidFileDelete(driver->pidDir, radvdpidbase);
-VIR_FREE(radvdpidbase);
-}
-network->radvdPid = -1;
-}
-/* now start radvd if it should be started */
-return networkStartRadvd(network);
-}
-#endif /* #if 0 */
-
 static int
 networkRefreshDaemonsHelper(virNetworkObjPtr net,
 void *opaque)
-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] news: Make changes understandable for users

2017-03-29 Thread Andrea Bolognani

On Tue, 2017-03-28 at 22:17 +0200, Martin Kletzander wrote:
> > This one looks like it would qualify on several accounts,
> > but it could also definitely use a description to flesh out
> > exactly what was changed, something along the lines of
> > 
> >   
> > Initialize volumes properly when building LVM storage pools
> >   
> >   
> > Volumes containing filesystem signatures need to have it
> > wiped out before they can be used in an LVM storage pools.
> > libvirt was unable to wipe out the signature for some
> > filesystem (such as ext4) but that limitation has now been
> > addressed.
> >   
> 
> Yeah, that's almost perfect (s/an LVM/LVM/), but I understand that not
> everyone wants to come up with such description.  It would not have to
> be if it was similarly worded in the commit message.

I'll be honest: it took me several passes (and several
minutes) to come up with that text, so I can see quite
clearly how not everyone would be willing to spend the
same amount of time and effort on release notes.

> Anyway, I guess I'm just overreacting to some of these changes.  I'm
> sorry for that.  I just feel like we went out of our ways to make
> something nicer for the users out there, and start falling back into the
> old tracks not long after it.  I compare it to git's release notes [1]
> which I always find a) very understandable and b) to the point
> (i.e. brief, no fuzzing around, but also missing only information you
> can easily find out yourself, e.g. in a man page), but I don't know why
> I'm so touchy regarding this subject.

Git's release notes have clearly been written and edited
by a single individual, so of course they're going to be
more consistent in tone and style than whatever our fairly
large community of contributors can come up with over the
span of a release.

My original intention was to be more active on this front
and provide more oversight, including editing entries
outright if necessary. I have unfortunately failed to do
a very good job so far, and I apologize for that.

But I wouldn't say all hope is lost: for starters, I'll
try to find some time to improve the release notes for
the current release before the end of the freeze. And
since you seem to be taking interest in the issue, maybe
we can both try to work on it on an ongoing basis? :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH resend V10 01/12] Resctrl: Add some utils functions

2017-03-29 Thread Martin Kletzander


On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:

hi Martin

(cc libvir-list)

I am a little confused about cat support.

I am currently rebasing my code on top of pre-cat branch from your private 
github repo, today when I check it you have removed it and create a cat branch 
and there are some related code pushed[1], can I know what ’s your plan for my 
patch set for CAT support ? should I continue my rebasing work? your though?



So we can work together on that.  Since the rework of the sysfs
functions, some patches are easier to write from scratch then rewrite,
but I'm now just trying to setup the test suite, so that we have
something to test on, at least some of the code.  So where are you in
the rebase right now?  Do you think anything from the virsysfs.c code
could be enhanced?


[1] 
https://github.com/nertpinx/libvirt/commit/c335de47a4efeca87f23e641a93587b1e036e558

Thanks Eli.



--
Best regards
Eli

天涯无处不重逢
a leaf duckweed belongs to the sea, where not to meet in life

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Friday, 24 March 2017 at 3:42 PM, Martin Kletzander wrote:


On Fri, Mar 24, 2017 at 09:35:33AM +0800, Eli Qiao wrote:
>
>
> --
> Best regards
> Eli
>
> 天涯无处不重逢
> a leaf duckweed belongs to the sea, where not to meet in life
>
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>
>
> On Thursday, 16 March 2017 at 3:52 PM, Eli Qiao wrote:
>
> >
> >
> > --
> > Best regards
> > Eli
> >
> > 天涯无处不重逢
> > a leaf duckweed belongs to the sea, where not to meet in life
> >
> > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> >
> >
> > On Wednesday, 15 March 2017 at 7:57 PM, Martin Kletzander wrote:
> >
> > > On Mon, Mar 06, 2017 at 06:06:30PM +0800, Eli Qiao wrote:
> > > > This patch adds some utils struct and functions to expose resctrl
> > > > information.
> > > >
> > > > virResCtrlAvailable: if resctrl interface exist on host.
> > > > virResCtrlGet: get specific type resource control information.
> > > > virResCtrlInit: initialize resctrl struct from the host's sys fs.
> > > > resctrlall[]: an array to maintain resource control information.
> > > >
> > > > Some of host cpu related information methods was added in virhostcpu.c
> > >
> > > So to be able to test all this we need to make a bit different approach.
> > > I'm not in favour of pushing this without proper tests. Some paths need
> > > to be configurable, some readings should be unified. Unfortunately lot
> > > of the code is just copy-paste mess from the past. Fortunately for you,
> > >
> > >
> > >
> > > I'm working on cleaning this up, at least a little bit, so that we can
> >
> > Good news.
> > > add the tests easily. I got almost up to the test (I stumbled upon few
> > > rabbit holes on the way and some clean-ups went wrong along the way), so
> > > it should be pretty easy for you to modify this code to use what I'll be
> > > proposing to add. It's not ready yet, but you can start rebasing your
> > > series on top of my branch pre-cat from my github repo [1]. The commits
> > > are not very well described right now (for some temporary ones I used
> > > whatthecommit.com (http://whatthecommit.com), sorry), but I'll fix all 
that. I'll be updating the
> > > branch, but it will be done with force pushes, so be careful when
> > > rebasing on top of newer versions.
> > >
> > > I can do that if you don't want, just let me know so we can coordinate.
> > of cause we can do some coordinate, but I am glad that you can help on this 
to speed up the progress to merge them, as you know this patch is in V10 already, and 
it has 12 patch set, kinds of hard to doing rebase… :(
> >
> >
> > > Just a quick heads-up, there will be virsysfs that will be used for the
> > > reads, some additional helper functions in virhostcpu and virfile, test
> > > that scans copy of /sys/devices/system (with that path faked thanks to
> > > using the aforementioned virsysfs) and outputs capabilities so that we
> > > can check the capability XML and so on.
> > >
> >
> >
> >
> > Ah, that’s a good news..
> > >
> > > Martin
> > >
> > > [1] https://github.com/nertpinx/libvirt
>
> hi Martin
>
> So, if I understand you correctly , you want all my patch set to rebased on 
top of pre-cat branch [1] , I checked that the last commit is 15th March, I wonder 
if that ’s ready to merged into master?
> so that I can start doing the rebasing
>


I forgot to do the usual push, it's updated now. The test fails in one
occasion, but it's the code's fault, the test is fine. That's the last
thing I'm looking at now, after that I'll send it to the list.

Look at the changes and see what you can use, it will help simplifying
your code a lot, I thing. You can start rebasing on top of that, I'll
do that as well after it's posted and I'll be either using and modifying
your patches or maybe doing some myself.

Martin




signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir

Re: [libvirt] [PATCH 1/2] networkUpdateState: Create virMacMap module more frequently

2017-03-29 Thread Michal Privoznik


On 03/28/2017 10:42 PM, Martin Kletzander wrote:



>

Makes sense to me, however you might want to look at an idea in the
second patch.  Maybe it would help a bit.  Maybe it wouldn't :-/


I feel like the consensus is either to have a pointer to an object (in 
which case it's enabled) or not have a pointer at all.




Anyway, even when I'm not against this, I'll leave ACKing this to Laine.


Fair enough. Thanks.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 2/4] news: Introduce rules for the schema file and fix offending lines

2017-03-29 Thread Peter Krempa

Add stricter rules for the news file and fix offending entries.
---
 docs/news.xml | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/docs/news.xml b/docs/news.xml
index b2e21efca..5115cb1ab 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -5,9 +5,18 @@
  This file will be processed to produce both HTML and plain text versions
  of the release notes.

- Keep the style consistent with existing entries as much as possible:
- each change should be documented by a short, one-sentence summary
- and optionally a description where it's explained in more detail -->
+ Keep the style consistent with existing entries as much as possible.
+
+ Each change should be documented by a short, one-sentence summary, which
+ should fit in a single line and should not contain any formatting tags.
+
+ You can optionally add a description if you feel like the summary alone is
+ not enough to document the change accurately. The description may contain
+ a  tag for switching to non-proportional font. No other tags are
+ allowed.
+
+ Lines should be kept under 80 columns, and should not exceed 100 columns.
+ -->

 
   
@@ -380,7 +389,7 @@
   
   
 
-  nss: Introduce libvirt_guest
+  nss: Introduce libvirt_guest
 
 
   New libvirt_guest nss module that translates libvirt
@@ -640,7 +649,7 @@
 
   The new libssh transport allows one to connect to a running
   libvirtd via SSH, using the libssh library; for example:
-  qemu+libssh://server/system.
+  qemu+libssh://server/system.
 
   
   
@@ -654,17 +663,22 @@
   
   
 
-  qemu: Users can now enable debug logging for native gluster
-  volumes in qemu using the "gluster_debug_level" option in qemu.conf
+  Allow debugging of gluster volumes in qemu
 
+
+  Users can now enable debug logging for native gluster
+  volumes in qemu using the "gluster_debug_level" option in qemu.conf
+
   
   
 
-  memory hotplug: Slot numbers for memory devices are now
-  automatically allocated and thus persistent. In addition slot numbers
-  can be specified without providing a base address, which simplifies
-  user configuration
+  Pre-allocate memory slots for memory hotplug
 
+
+  Slot numbers for memory devices are now automatically allocated and
+  thus persistent. In addition slot numbers can be specified without
+  providing a base address, which simplifies user configuration
+
   
   
 
@@ -694,8 +708,7 @@
   
   
 
-  virsh: Add support for passing an alternative persistent XML
-  to migrate command
+  virsh: Add support for passing an alternative persistent XML to 
migrate command
 
   
   
-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 4/4] news: Add template for a section

2017-03-29 Thread Peter Krempa

After the release it's necessary to add a new  section for the
upcoming release. Add a template so that it does not have to be
compiled over and over again.
---
 docs/news.xml | 21 +
 1 file changed, 21 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index d9c39d026..9f3538394 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -18,6 +18,27 @@
  Lines should be kept under 80 columns, and should not exceed 100 columns.

  This file is validated against docs/schemas/news.rng schema.
+
+ Use the following template to add a new release section:
+
+  
+
+  
+
+  
+
+
+  
+
+  
+
+
+  
+
+  
+
+  
+
  -->

 
-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 1/4] tests: schema: Add possibility to validate individual files

2017-03-29 Thread Peter Krempa

Sometimes it may be desired to validate individual files against a
schema. Refactor the data structures to unify them and introduce a new
macro DO_TEST_FILE(schema, xmlfile) which will test the XML file against
the given schema file.
---
 tests/virschematest.c | 75 ---
 1 file changed, 47 insertions(+), 28 deletions(-)

diff --git a/tests/virschematest.c b/tests/virschematest.c
index faf66d642..b73555da8 100644
--- a/tests/virschematest.c
+++ b/tests/virschematest.c
@@ -35,6 +35,7 @@ VIR_LOG_INIT("tests.schematest");

 struct testSchemaData {
 virXMLValidatorPtr validator;
+const char *schema;
 const char *xml_path;
 };

@@ -140,15 +141,10 @@ testSchemaDirs(const char *schema, virXMLValidatorPtr 
validator, ...)
 }


-struct testSchemaFileData {
-virXMLValidatorPtr validator;
-const char *schema;
-};
-
 static int
 testSchemaGrammar(const void *opaque)
 {
-struct testSchemaFileData *data = (struct testSchemaFileData *) opaque;
+struct testSchemaData *data = (struct testSchemaData *) opaque;
 char *schema_path;
 int ret = -1;

@@ -171,11 +167,11 @@ static int
 mymain(void)
 {
 int ret = 0;
-struct testSchemaFileData data;
+struct testSchemaData data;

 memset(&data, 0, sizeof(data));

-#define DO_TEST(sch, ...)  
\
+#define DO_TEST_DIR(sch, ...)  
\
 do {   
\
 data.schema = sch; 
\
 if (virTestRun("test schema grammar file: " sch,   
\
@@ -196,26 +192,49 @@ mymain(void)
 }  
\
 } while (0)

-DO_TEST("capability.rng", "capabilityschemadata", "xencapsdata");
-DO_TEST("domain.rng", "domainschemadata", "qemuargv2xmldata",
-"qemuxml2argvdata", "sexpr2xmldata", "xmconfigdata",
-"xml2sexprdata", "qemuxml2xmloutdata", "lxcxml2xmldata",
-"lxcxml2xmloutdata", "bhyvexml2argvdata", "genericxml2xmlindata",
-"genericxml2xmloutdata", "xlconfigdata",
-"qemuhotplugtestdomains");
-DO_TEST("domaincaps.rng", "domaincapsschemadata");
-DO_TEST("domainsnapshot.rng", "domainsnapshotxml2xmlin",
-"domainsnapshotxml2xmlout");
-DO_TEST("interface.rng", "interfaceschemadata");
-DO_TEST("network.rng", "../src/network", "networkxml2xmlin",
-"networkxml2xmlout", "networkxml2confdata");
-DO_TEST("nodedev.rng", "nodedevschemadata");
-DO_TEST("nwfilter.rng", "nwfilterxml2xmlout");
-DO_TEST("secret.rng", "secretxml2xmlin");
-DO_TEST("storagepool.rng", "storagepoolxml2xmlin", "storagepoolxml2xmlout",
-"storagepoolschemadata");
-DO_TEST("storagevol.rng", "storagevolxml2xmlin", "storagevolxml2xmlout",
-"storagevolschemadata");
+#define DO_TEST_FILE(sch, xmlfile) 
\
+do {   
\
+data.schema = sch; 
\
+data.xml_path = abs_srcdir "/" xmlfile;
\
+if (virTestRun("test schema grammar file: " sch,   
\
+   testSchemaGrammar, &data) == 0) {   
\
+/* initialize the validator even if the schema test
\
+ * was skipped because of VIR_TEST_RANGE */
\
+if (!data.validator && testSchemaGrammar(&data) < 0) { 
\
+ret = -1;  
\
+break; 
\
+}  
\
+if (virTestRun("Checking " xmlfile " against " sch,
\
+   testSchemaFile, &data) < 0) 
\
+ret = -1;  
\
+   
\
+virXMLValidatorFree(data.validator);   
\
+data.validator = NULL; 
\
+} else {   
\
+ret = -1;  
\
+}  
\
+} while (0)
+
+DO_TEST_DIR("capability.rng", "capabilityschemadata", "xencapsdata");
+DO_TEST_DIR("domain.rng", "domainschemadata", "qemuargv2xmldata",
+"qemuxml2argvdata", "sexpr2xmldata", "xmconfigdata

[libvirt] [PATCH v2 3/4] schema: Introduce schema for the news.xml file

2017-03-29 Thread Peter Krempa

Since this file gets changed (and broken) rather often, introduce a
schema file so that the test suite can validate it.
---
 docs/news.xml |  2 ++
 docs/schemas/news.rng | 73 +++
 tests/virschematest.c |  2 ++
 3 files changed, 77 insertions(+)
 create mode 100644 docs/schemas/news.rng

diff --git a/docs/news.xml b/docs/news.xml
index 5115cb1ab..d9c39d026 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -16,6 +16,8 @@
  allowed.

  Lines should be kept under 80 columns, and should not exceed 100 columns.
+
+ This file is validated against docs/schemas/news.rng schema.
  -->

 
diff --git a/docs/schemas/news.rng b/docs/schemas/news.rng
new file mode 100644
index 0..94a6870c1
--- /dev/null
+++ b/docs/schemas/news.rng
@@ -0,0 +1,73 @@
+
+http://relaxng.org/ns/structure/1.0"; 
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes";>
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  v[0-9]+\.[0-9]+\.[0-9]+
+
+  
+  
+
+  [0-9]{4}-[0-9]{2}-[0-9]{2}|unreleased
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+\n[^\n]+\n +
+  
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+
+  
+
+  
+
+  
+
+
diff --git a/tests/virschematest.c b/tests/virschematest.c
index b73555da8..4f194804a 100644
--- a/tests/virschematest.c
+++ b/tests/virschematest.c
@@ -236,6 +236,8 @@ mymain(void)
 DO_TEST_DIR("storagevol.rng", "storagevolxml2xmlin", 
"storagevolxml2xmlout",
 "storagevolschemadata");

+DO_TEST_FILE("news.rng", "../docs/news.xml");
+
 return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
 }

-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 0/4] Add schema validation for news

2017-03-29 Thread Peter Krempa

v2:
- rename DO_TEST to DO_TEST_DIR along with changes in the first patch
- add 'abs_srcdir' to the tested XML path so that vpath builds work
- fix wording of the rules for adding news entries
- fix commit messages

Peter Krempa (4):
  tests: schema: Add possibility to validate individual files
  news: Introduce rules for the schema file and fix offending lines
  schema: Introduce schema for the news.xml file
  news: Add template for a  section

 docs/news.xml | 62 -
 docs/schemas/news.rng | 73 
 tests/virschematest.c | 77 ---
 3 files changed, 171 insertions(+), 41 deletions(-)
 create mode 100644 docs/schemas/news.rng

-- 
2.12.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] encountered failed test cases with latest checkout of libvirt

2017-03-29 Thread Dan

On Wed, Mar 29, 2017 at 1:01 AM, D L  wrote:

> Hi all,
>
> This email content might be duplicated with other thread posted in other
> places that I do not know yet where to find or search (please let me know
> if it is true). I am working on a small bug of virsh domxml-to-native.
> Before I made any changes to the code in order to fix the bug, I 'make
>  test'-ed and 'valgrind test'-ed the code, encountered four failures in
> 'make test' and 19 failures in 'make -C tests valgrind'. What I did today
> was the following:
>
> git checkout master
> git pull
> ./autogen.sh --prefix=$(pwd)/build
> make
> make install
> # So far so good, no errors ; however
>
> make check VIR_TEST_EXPENSIVE=1
> # generated the following test-suite.log
> =
>libvirt 3.2.0: tests/test-suite.log
> =
>
> # TOTAL: 115
> # PASS:  111
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  4
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: virfirewalltest
> =
>
> TEST: virfirewalltest
>    40  FAIL
> FAIL virfirewalltest (exit status: 1)
>
> FAIL: networkxml2firewalltest
> =
>
> TEST: networkxml2firewalltest
>  0   FAIL
> FAIL networkxml2firewalltest (exit status: 1)
>
> FAIL: nwfilterebiptablestest
> 
>
> TEST: nwfilterebiptablestest
>  0   FAIL
> FAIL nwfilterebiptablestest (exit status: 1)
>
> FAIL: nwfilterxml2firewalltest
> ==
>
> TEST: nwfilterxml2firewalltest
>  0   FAIL
> FAIL nwfilterxml2firewalltest (exit status: 1)
>
>
>
> make syntax-check VIR_TEST_EXTENSIVE=1
> # I did not paste the result here and I do not understand what it means.
> # available upon request
>
> Finally,
> make -C tests valgrind
> # generated file was attached.
>
> It seems most of the valgrind failures were false positives, I can only
> tell
> by comparing the log file with the examples in the HACKING page. But I
> do not have the knowledge to determine.
>
> Could anyone tell me if I am missing something? Having those test failures
> is a problem or not? Which ones can be safely ignored? Is there any easier
> way to avoid the false positives? I am concerned because I also need to
> run the test when I make changes to the code. On the other hand, I would
> also like to learn the right way to do the testing or whatever it takes to
> make
> things right.
>
> I am running linux using vmware Workstation Pro 12 on Windows 10.
> Linux version 4.4.55-1-MANJARO (builduser@manjaro) (gcc version 6.3.1
> 20170306 (GCC) ) #1 SMP PREEMPT
>
>
>
> Dan
>
>
>
> On ubuntu16 and ubuntu14, ebtables were pre-installed. But on
Archlinux and Debian, ebtables have to be installed explicitly in order to
pass
all test cases in 'make check'.  I found out this after I enabled debugging
checking
$ make check VIR_TEST_DEBUG=2 VIR_TEST_EXPENSIVE=1

For the valgrind testing with 'make -C tests valgrind', the errors were
*mostly* due to
"FATAL: can't open suppressions file "./.valgrind.supp". I am using
valgrind 3.12.0.

Dan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

87 matches

Mail list logo