Re: [libvirt] [PATCH] virsh.pod: Mention iscsi-direct is supported in find-storage-pool-sources

2019-12-13 Thread Cole Robinson
On 12/4/19 4:19 AM, Han Han wrote:
> Signed-off-by: Han Han 
> ---
>  tools/virsh.pod | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/virsh.pod b/tools/virsh.pod
> index a8331154e1..14f4121787 100644
> --- a/tools/virsh.pod
> +++ b/tools/virsh.pod
> @@ -3994,7 +3994,8 @@ any other provided XML elements in I.
>  For a "logical" pool, the contents of the I file are ignored,
>  although if provided the file must at least exist.
>  
> -For an "iscsi" pool, the minimal expect XML required is the  element
> +For an "iscsi" or "iscsi-direct" pool,
> +the minimal expect XML required is the  element
>  with a "name" attribute describing the IP address or hostname to be used to
>  find the pool (the iSCSI server address). Optionally, the "port" attribute
>  may be provided, although it will default to 3260. Optionally, an 
> 

I adjusted this for the new .rst man page format, and pushed

Thanks,
Cole

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



Re: [libvirt] [PATCH v3 0/6] PCI hostdev partial assignment support

2019-12-13 Thread Cole Robinson
On 12/12/19 4:41 PM, Daniel Henrique Barboza wrote:
> 
> 
> On 12/11/19 8:49 PM, Cole Robinson wrote:
>> On 11/26/19 8:33 AM, Daniel Henrique Barboza wrote:
>>> changes from previous version [1]:
> [...]
>>
>> One comment
>>
>>> Daniel Henrique Barboza (6):
>>>    Introducing new address type='unassigned' for PCI hostdevs
>>>    qemu: handle unassigned PCI hostdevs in command line and alias
>>
>> Is there a specific reason to skip alias assign, beside it not being
>> needed for the command line? If it doesn't hurt, maybe we just keep it.
>> I don't have a strong argument for it though. If no one says anything
>> I'll leave it as is
> 
> 
> The reason why I was skipping aliases was cosmetic due to QEMU command
> line.
> I find it a bit odd that, in a scenario with 4 functions where function
> 1 is
> unassigned, QEMU cmd line would have hostdev0, hostdev2 and hostdev3,
> because
> 'hostdev1' alias got assigned to the unassigned function '1'
> 
> I don't have any strong feelings about this though. We can keep giving
> aliases
> or all functions, regardless of whether they are being assigned to the
> guest or not. Unit tests will need to be adjusted though.
> 
> 
> 
>>
>>>    virhostdev.c: check all IOMMU devs in virHostdevPreparePCIDevices
>>>    formatdomain.html.in: document 
>>
>> For the first 4 I'll give it a few days and push on Friday if no one
>> complains.
>>
>> For the last two:
>>
>>>    utils: PCI multifunction detection helpers
>>>    domain_conf.c: don't allow function zero to be unassigned
>>
>> The domain_conf.c additions should go into the
>> virDomainHostdevDefValidate. But this validation check seems to actually
>> read from host PCI space. I'm not sure if that's a good idea to do for
>> every XML parse? What's the failure scenario without this error message?
>> Does it fail in an obvious way? If so, maybe it's better to side step
>> the issue and just let it fail if it's a valid configuration.
> 
> This is a strange scenario TBH. I discussed it a bit with Alex
> Williamson in
> the v2 of this series. At first there is nothing wrong with this, in fact
> QEMU allows it. Problem is that Power guests handle this case in a
> "better" way
> than x86 and others, making the non-zero function being visible and usable
> by the guest without any extra kernel option (x86 needs pci_scan_all). It's
> also hardware dependent - the BCM5719 network card I am using for testing
> deals with this scenario, but there's no guarantee that other cards will.
> 
> To answer your question directly: this might not fail in an obvious way in
> the guest, but it's not like this feature is a default PCI assignment
> mode - the user have to deliberately unassigned the function 0 in the XML.
> Granted, I am being conservative with this extra check - we can simply let
> the user play with the configuration and, in case it blows up, the user
> can simply add function 0 back to the guest. If this turns out to be a
> "toxic" setup then I can go to QEMU and deal with it there - I mean, in the
> end it's QEMU that allows this, so makes sense to handle the case down
> there.

Okay I think we should drop the last two patches then.

Small change of plan: Please respin this series with the alias changes
dropped. Also in the docs patch, the version needs to be updated to
6.0.0, I missed that the first time. After that I will push

Thanks,
Cole

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

Re: [libvirt] [PATCH v4 2/7] virConnectRegisterCloseCallback: Cleanup 'opaque' if there is no connectRegisterCloseCallback

2019-12-13 Thread Cole Robinson
On 12/12/19 8:46 AM, Marc Hartmayer wrote:
> On Wed, Dec 11, 2019 at 08:11 PM -0500, Cole Robinson  
> wrote:
>> On 11/14/19 12:44 PM, Marc Hartmayer wrote:
>>> The commit 'close callback: move it to driver' (88f09b75eb99) moved
>>> the responsibility for the close callback to the driver. But if the
>>> driver doesn't support the connectRegisterCloseCallback API this
>>> function does nothing, even no unsupported error report. This behavior
>>> may lead to problems, for example memory leaks, as the caller cannot
>>> differentiate whether the close callback was 'really' registered or
>>> not.
>>>
>>
>>
>> Full context:
>> v1 subtrhead with jferlan and danpb:
>> https://www.redhat.com/archives/libvir-list/2018-March/msg00906.html
>> https://www.redhat.com/archives/libvir-list/2018-April/msg00116.html
>>
>> v2 subthread with john:
>> https://www.redhat.com/archives/libvir-list/2018-April/msg02534.html
>>
>> My first thought is, why not just make this API start raising an error
>> if it isn't supported?
>>
>> But you tried that here:
>> https://www.redhat.com/archives/libvir-list/2018-March/msg00405.html
> 
> First, thanks for doing all the “history research”.
> 
>>
>> I'm not really sure I buy the argument that we can't change the
>> semantics of the API here. This is the only callback API that seems to
>> not raise an explicit error. It's documented to raise an error. And
>> there's possible memory leak due the ambiguity.
> 
> If we’re doing this so let’s fix the behavior of
> 'virConnectUnregisterCloseCallback' as well.
> 
>>
>> Yeah I see that virsh needs to be updated to match. In practice virsh
>> shouldn't be a problem: this issue will only hit for local drivers, and
>> virsh and client library will be updated together for that case.
>>
>> In theory if a python app is using this API and not expecting an
>> exception, it could cause a regression. But it's also informing them
>> that, hey, that connection callback you requested wasn't working in the
>> first place. So it's arguably a correctness issue.
>>
>> So IMO we should be able to adjust this to return a proper error.
>>
>>
>> BUT, if we stick with this direction, then we need to extend the doc
>> text here to describe all of this:
>>
>> * Returns -1 if the driver can support close callback, but registering
>> one failed. User must free opaque?
>> * Returns 0 if the driver does not support close callback. We will free
>> data for you
>> * Returns 0 if the driver successfully registered a close callback. When
>> that callback is triggered, opaque will be free'd
>>
>> But that sounds pretty nutty IMO :/
> 
> I know…

I did a bit more digging. Even the virsh case isn't the biggest deal
because CloseCallback failing is non-fatal. But like I mentioned before
it shouldn't realistically be hit in practice because we can expect
virsh and libvirt-client to be updated in lockstep.

virt-manager, libguestfs, vdsm, kubevirt don't use this API
nova does (nova/virt/libvirt/host.py) but it has code to catch the error

So IMO this should be changed to have semantics like all the other event
functions. Yes it's a semantic change, but I see it as explicitly
erroring in a case that never actually worked. We've made changes like
that many times, happens with XML validation semi regularly, and the
UNDEFINE flag changes are other notable examples.

danpb has your thinking changed on this? Previous discussion context is
in this thread:
https://www.redhat.com/archives/libvir-list/2018-April/msg00116.html

Thanks,
Cole

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

Re: [libvirt] [PATCH v4 6/7] remote: shrink the critical sections

2019-12-13 Thread Cole Robinson
On 12/12/19 9:13 AM, Marc Hartmayer wrote:
> On Wed, Dec 11, 2019 at 07:48 PM -0500, Cole Robinson  
> wrote:
>> On 11/14/19 12:44 PM, Marc Hartmayer wrote:
>>> To free the structs and save the error, it is not necessary to hold 
>>> @priv->lock,
>>> therefore move these parts after the mutex unlock.
>>>
>>> Signed-off-by: Marc Hartmayer 
>>> ---
>>>  src/remote/remote_daemon_dispatch.c | 32 ++---
>>>  1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> Reviewed-by: Cole Robinson 
>>
>> Do I understand correctly that 1,3-5 are all independent and can be
>> pushed separately? If so I will do that tomorrow. I'm doing some
>> archaeology on patch #2
> 
> 1, 3, and 5 are all independent.
> 
> Patch 4 depends on the second patch as
> remoteDispatchConnectRegisterCloseCallback uses
> virConnectRegisterCloseCallback. Otherwise we would never do the unref
> for @client and @program when conn->driver->connectRegisterCloseCallback
> was NULL.

Thanks, I pushed 1, 3, 5, 6. I'll reply to your other message

- Cole

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



Re: [libvirt] [jenkins-ci PATCH v3 4/7] guests: pull in deps for gtk-vnc project

2019-12-13 Thread Andrea Bolognani
On Fri, 2019-12-13 at 14:36 +, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé 
> ---
>  guests/host_vars/libvirt-centos-7/main.yml|  1 +
>  guests/host_vars/libvirt-centos-8/main.yml|  1 +
>  guests/host_vars/libvirt-debian-10/main.yml   |  1 +
>  guests/host_vars/libvirt-debian-9/main.yml|  1 +
>  guests/host_vars/libvirt-debian-sid/main.yml  |  1 +
>  guests/host_vars/libvirt-fedora-30/main.yml   |  3 +++
>  guests/host_vars/libvirt-fedora-31/main.yml   |  1 +
>  guests/host_vars/libvirt-fedora-rawhide/main.yml  |  1 +
>  guests/host_vars/libvirt-freebsd-11/main.yml  |  1 +
>  guests/host_vars/libvirt-freebsd-12/main.yml  |  1 +
>  guests/host_vars/libvirt-freebsd-current/main.yml |  1 +
>  guests/host_vars/libvirt-ubuntu-1604/main.yml |  1 +
>  guests/host_vars/libvirt-ubuntu-1804/main.yml |  1 +
>  guests/vars/projects/gtk-vnc+mingw32.yml  |  7 +++
>  guests/vars/projects/gtk-vnc+mingw64.yml  |  7 +++
>  guests/vars/projects/gtk-vnc.yml  | 12 
>  16 files changed, 41 insertions(+)
>  create mode 100644 guests/vars/projects/gtk-vnc+mingw32.yml
>  create mode 100644 guests/vars/projects/gtk-vnc+mingw64.yml
>  create mode 100644 guests/vars/projects/gtk-vnc.yml

Tentative

  Reviewed-by: Andrea Bolognani 

but we might have to drop the project from some targets if we can't
figure out a way to build it on them...

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [jenkins-ci PATCH v3 3/7] mappings: add gdk-pixbuf

2019-12-13 Thread Andrea Bolognani
On Fri, 2019-12-13 at 14:36 +, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé 
> ---
>  guests/vars/mappings.yml | 12 
>  1 file changed, 12 insertions(+)

Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [jenkins-ci PATCH v3 5/7] projects: add gtk-vnc project

2019-12-13 Thread Andrea Bolognani
On Fri, 2019-12-13 at 14:36 +, Daniel P. Berrangé wrote:
> +++ b/guests/playbooks/build/projects/gtk-vnc+mingw64.yml
> @@ -0,0 +1,12 @@
> +---
> +- set_fact:
> +name: gtk-vnc+mingw64
> +machines: '{{ mingw_machines }}'
> +archive_format: xz
> +git_url: '{{ git_urls["gtk-vnc"][git_remote] }}'
> +
> +- include: '{{ playbook_base }}/jobs/prepare.yml'
> +- include: '{{ playbook_base }}/jobs/meson-build-job.yml'
> +  vars:
> +local_env: '{{ mingw64_local_env }}'
> +meson_args: '{{ mingw32_meson_args }}'

s/mingw32/mingw64/

> +++ b/guests/playbooks/build/projects/gtk-vnc.yml
> @@ -0,0 +1,19 @@
> +---
> +- set_fact:
> +name: gtk-vnc
> +machines: '{{ all_machines }}'
> +archive_format: xz
> +git_url: '{{ git_urls["gtk-vnc"][git_remote] }}'
> +
> +- include: '{{ playbook_base }}/jobs/prepare.yml'
> +- include: '{{ playbook_base }}/jobs/meson-build-job.yml'

Build fails on FreeBSD with

  $ meson .. . --prefix=$VIRT_PREFIX
  The Meson build system
  Version: 0.52.1
  Source dir: /usr/home/test/gtk-vnc
  Build dir: /usr/home/test/gtk-vnc/build
  Build type: native build
  Project name: gtk-vnc
  Project version: 1.0.0
  C compiler for the host machine: ccache cc (clang 6.0.1 "FreeBSD clang 
version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)")
  C linker for the host machine: lld 6.0.1
  Host machine cpu family: x86_64
  Host machine cpu: x86_64
  Program pod2man found: YES (/usr/local/bin/pod2man)
  Found pkg-config: /usr/local/bin/pkg-config (1.6.3)
  Run-time dependency gobject-2.0 found: YES 2.56.3
  Run-time dependency gio-2.0 found: YES 2.56.3
  Run-time dependency gio-unix-2.0 found: YES 2.56.3
  Run-time dependency gdk-pixbuf-2.0 found: YES 2.38.1
  Did not find CMake 'cmake'
  Found CMake: NO
  Run-time dependency gtk+-3.0 found: NO

  meson.build:81:0: ERROR: Could not generate cargs for gtk+-3.0:
  Package xproto was not found in the pkg-config search path.
  Perhaps you should add the directory containing `xproto.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'xproto', required by 'x11', not found
  Package 'kbproto', required by 'x11', not found
  Package 'xextproto', required by 'xext', not found
  Package 'xproto', required by 'xdamage', not found
  [...]

The issue is not in Meson itself:

  $ pkg-config --cflags --libs gtk+-3.0
  Package xproto was not found in the pkg-config search path.
  Perhaps you should add the directory containing `xproto.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'xproto', required by 'x11', not found
  Package 'kbproto', required by 'x11', not found
  Package 'xextproto', required by 'xext', not found
  Package 'xproto', required by 'xdamage', not found
  [...]

so it looks like it's most likely a packaging issue.

On Debian 9, it fails with

  [...]
  [56/64] Linking target src/libgtk-vnc-2.0.so.0.0.2.
  FAILED: src/libgtk-vnc-2.0.so.0.0.2
  ccache cc  -o src/libgtk-vnc-2.0.so.0.0.2 
'src/25a6634@@gtk-vnc-2.0@sha/meson-generated_.._vncdisplayenums.c.o' 
'src/25a6634@@gtk-vnc-2.0@sha/meson-generated_.._vncmarshal.c.o' 
'src/25a6634@@gtk-vnc-2.0@sha/meson-generated_.._vncconnectionenums.c.o' 
'src/25a6634@@gtk-vnc-2.0@sha/vncdisplay.c.o' 
'src/25a6634@@gtk-vnc-2.0@sha/vncgrabsequence.c.o' 
'src/25a6634@@gtk-vnc-2.0@sha/vnccairoframebuffer.c.o' 
'src/25a6634@@gtk-vnc-2.0@sha/vncdisplaykeymap.c.o' -Wl,--no-undefined 
-Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libgtk-vnc-2.0.so.0 
src/libgvnc-1.0.so.0.0.1 -Wl,--no-undefined 
-Wl,--version-script,/home/test/gtk-vnc/src/libgtk-vnc_sym.version 
/usr/lib/x86_64-linux-gnu/libgtk-3.so /usr/lib/x86_64-linux-gnu/libgdk-3.so 
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so 
/usr/lib/x86_64-linux-gnu/libpango-1.0.so 
/usr/lib/x86_64-linux-gnu/libatk-1.0.so 
/usr/lib/x86_64-linux-gnu/libcairo-gobject.so 
/usr/lib/x86_64-linux-gnu/libcairo.so 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so -lgcrypt 
/usr/lib/x86_64-linux-gnu/libgnutls.so /usr/lib/x86_64-linux-gnu/libsasl2.so 
/usr/lib/x86_64-linux-gnu/libz.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/' 
-Wl,-rpath-link,/home/test/gtk-vnc/build/src
  src/25a6634@@gtk-vnc-2.0@sha/vncdisplaykeymap.c.o: In function 
`vnc_display_keymap_gdk2rfb_table':
  /home/test/gtk-vnc/build/../src/vncdisplaykeymap.c:150: undefined reference 
to `XkbGetMap'
  /home/test/gtk-vnc/build/../src/vncdisplaykeymap.c:154: undefined reference 
to `XkbGetNames'
  /home/test/gtk-vnc/build/../src/vncdisplaykeymap.c:163: undefined reference 
to `XkbFreeKeyboard'
  src/25a6634@@gtk-vnc-2.0@sha/vncdisplaykeymap.c.o: In function 
`check_for_xquartz':
  /home/test/gtk-vnc/build/../src/vncdisplaykeymap.c:116: undefined reference 
to `XListExtensions'
  /home/test/gtk-vnc/build/../src/vncdisplaykeymap.c:125: undefined reference 
to `XFreeExtensionList'
  

Re: [libvirt] [libvirt-tck PATCH] Add cases for nvram

2019-12-13 Thread Daniel P . Berrangé
On Fri, Dec 13, 2019 at 04:59:24PM +0800, Dan Zheng wrote:
> This is to add the tests for below flags:
> - Sys::Virt::Domain::UNDEFINE_KEEP_NVRAM
> - Sys::Virt::Domain::UNDEFINE_NVRAM
> 
> Signed-off-by: Dan Zheng 
> ---
>  scripts/domain/401-ovmf-nvram.t | 143 
>  1 file changed, 143 insertions(+)
>  create mode 100644 scripts/domain/401-ovmf-nvram.t
> 
> diff --git a/scripts/domain/401-ovmf-nvram.t b/scripts/domain/401-ovmf-nvram.t
> new file mode 100644
> index 000..5310dd0
> --- /dev/null
> +++ b/scripts/domain/401-ovmf-nvram.t
> @@ -0,0 +1,143 @@
> +# -*- perl -*-
> +#
> +# Copyright (C) 2009 Red Hat, Inc.
> +# Copyright (C) 2018 Dan Zheng (dzh...@redhat.com)
> +#
> +# This program is free software; You can redistribute it and/or modify
> +# it under the GNU General Public License as published by the Free
> +# Software Foundation; either version 2, or (at your option) any
> +# later version
> +#
> +# The file "LICENSE" distributed along with this file provides full
> +# details of the terms and conditions
> +#
> +
> +=pod
> +
> +=head1 NAME
> +
> +domain/401-ovmf-nvram.t - Test OVMF related functions and flags
> +
> +=head1 DESCRIPTION
> +
> +The test cases validates OVMF related APIs and flags
> +
> +Sys::Virt::Domain::UNDEFINE_KEEP_NVRAM
> +Sys::Virt::Domain::UNDEFINE_NVRAM
> +
> +=cut
> +
> +use strict;
> +use warnings;
> +
> +use Test::More tests => 8;
> +
> +use Sys::Virt::TCK;
> +use File::stat;
> +use File::Copy;
> +
> +
> +my $tck = Sys::Virt::TCK->new();
> +my $conn = eval { $tck->setup(); };
> +BAIL_OUT "failed to setup test harness: $@" if $@;
> +END { $tck->cleanup if $tck; }
> +
> +
> +sub setup_nvram {
> +
> +my $loader_path = shift;
> +my $nvram_template = shift;
> +my $nvram_path = shift;

Everything inside the function should be indented 4 space.

> +
> +# Install OVMF and check the two files should exist
> +#  - /usr/share/OVMF/OVMF_CODE.secboot.fd
> +#  - /usr/share/OVMF/OVMF_VARS.fd
> +
> +my $ret = `yum install -y OVMF`;
> +diag "yum install OVMF: $ret";

We shouldn't install extra RPMs in the scripts really. Insxtead
we should look to see if the files we need exist or not. If they
don't exist, then we shuld return 'undef' from this method. THe
caller should then arrange to skip execution of the rest of the
test.

> +my $st = stat($loader_path);
> +ok($st, "path $loader_path exists after OVMF is installed");
> +$st = stat($nvram_template);
> +ok($st, "path $nvram_template exists after OVMF is installed");
> +
> +# Ensure the sample nvram file exists
> +copy($nvram_template, $nvram_path) or die "Copy failed: $!";
> +
> +# Use 'q35' as machine type and add below lines to guest xml
> +#  type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd
> +#  template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/test_VARS.fd
> +
> +my $xml = $tck->generic_domain(name => "tck")->as_xml;
> +my $xp = XML::XPath->new($xml);
> +diag $xp->getNodeText("/domain/os/type/\@machine");
> +
> +diag "Changing guest machine type to q35";
> +$xp->setNodeText("/domain/os/type/\@machine", "q35");
> +
> +my $loader_node = XML::XPath::Node::Element->new('loader');
> +my $loader_text   = XML::XPath::Node::Text->new($loader_path);
> +my $attr_ro = XML::XPath::Node::Attribute->new('readonly');
> +my $attr_secure = XML::XPath::Node::Attribute->new('secure');
> +my $attr_type = XML::XPath::Node::Attribute->new('type');
> +
> +$attr_ro -> setNodeValue('yes');
> +$attr_secure -> setNodeValue('yes');
> +$attr_type   -> setNodeValue('pflash');
> +
> +$loader_node->appendChild($loader_text);
> +$loader_node->appendAttribute($attr_ro);
> +$loader_node->appendAttribute($attr_secure);
> +$loader_node->appendAttribute($attr_type);
> +
> +my $nvram_node= XML::XPath::Node::Element->new('nvram');
> +my $nvram_text= XML::XPath::Node::Text->new($nvram_path);
> +my $attr_template = XML::XPath::Node::Attribute->new('template');
> +
> +$attr_template -> setNodeValue($nvram_template);
> +
> +$nvram_node->appendChild($nvram_text);
> +$nvram_node->appendAttribute($attr_template);
> +
> +my $smm_node   = XML::XPath::Node::Element->new('smm');
> +my $attr_state = XML::XPath::Node::Attribute->new('state');
> +$attr_state -> setNodeValue("on");
> +$smm_node -> appendAttribute($attr_state);
> +
> +my ($root) = $xp->findnodes('/domain/os');
> +$root->appendChild($loader_node);
> +$root->appendChild($nvram_node);
> +($root) = $xp->findnodes('/domain/features');
> +$root->appendChild($smm_node);
> +
> +$xml = $xp->findnodes_as_string('/');
> +diag $xml;
> +return $xml;
> +}
> +
> +diag "Defining an inactive domain config with nvram";
> +my $loader_file_path = '/usr/share/OVMF/OVMF_CODE.secboot.fd';
> +my $nvram_file_template = '/usr/share/OVMF/OVMF_VARS.fd';
> +my $nvram_file_path = '/var/lib/libvirt/qemu/nvram/test_VARS.fd';
> +
> +my $xml = setup_nvram($loader_file_path, $nvram_file_template, 
> $nvram_file_path);
> +my $dom;
> +
> +diag "Test 

[libvirt] [tck PATCH] Update x86_64 image & virt-builder image to F31

2019-12-13 Thread Daniel P . Berrangé
i386 was dropped even as a secondary arch in F31 so must remain
on F30

Signed-off-by: Daniel P. Berrangé 
---
 conf/default.cfg | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/conf/default.cfg b/conf/default.cfg
index 39d9b04..3493ad7 100644
--- a/conf/default.cfg
+++ b/conf/default.cfg
@@ -49,7 +49,7 @@ images = (
   hvm
   xen
 )
-osname = fedora-30
+osname = fedora-31
   }
 )
 
@@ -76,6 +76,7 @@ images = (
 #
 kernels = (
# Fedora 30 i686 PAE has pv_ops, so one kernel can do both Xen and KVM 
guests here
+   # No i386 releases since F30
{
  arch = i686
  ostype = (
@@ -85,15 +86,15 @@ kernels = (
  kernel = 
http://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Everything/i386/os/images/pxeboot/vmlinuz
  initrd = 
http://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Everything/i386/os/images/pxeboot/initrd.img
}
-   # Fedora 30 x86_64 has pv_ops, so one kernel can do both Xen and KVM guests 
here
+   # Fedora 31 x86_64 has pv_ops, so one kernel can do both Xen and KVM guests 
here
{
  arch = x86_64
  ostype = (
hvm
xen
  )
- kernel = 
http://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/os/images/pxeboot/vmlinuz
- initrd = 
http://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/os/images/pxeboot/initrd.img
+ kernel = 
http://dl.fedoraproject.org/pub/fedora/linux/releases/31/Everything/x86_64/os/images/pxeboot/vmlinuz
+ initrd = 
http://dl.fedoraproject.org/pub/fedora/linux/releases/31/Everything/x86_64/os/images/pxeboot/initrd.img
}
# LXC containers need a virtual container filesystem somewhere
 #   {
-- 
2.23.0

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

[libvirt] [PATCH] cpu_map/x86: Add support for BFLOAT16 data type

2019-12-13 Thread Jiri Denemark
Introduced in QEMU by commit v4.1.0-266-g80db491da4.

Signed-off-by: Jiri Denemark 
---
 src/cpu_map/x86_features.xml | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml
index b42b490160..eefb55067e 100644
--- a/src/cpu_map/x86_features.xml
+++ b/src/cpu_map/x86_features.xml
@@ -339,6 +339,10 @@
 
   
 
+  
+
+  
+
   
   
 
-- 
2.24.1

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



Re: [libvirt] [PATCH 0/5] Introduce the support of Intel RDT-MBM

2019-12-13 Thread Daniel P . Berrangé
On Thu, Nov 14, 2019 at 01:08:18AM +0800, Wang Huaqiang wrote:
> RDT is the short for Intel Resource Director Technology, consists
> of four sub-technologies until now:
> 
> -. CAT for cache allocation
> -. CMT for cache usage monitoring
> -. MBA for memory bandwidth allocation
> -. MBM for memory bandwidth usage monitoring
> 
> The Linux kernel interface is 'resctrl' file system, and we have
> already implemented the support of CAT, CMT and MBA, to accomplish
> the tasks such as allocating a part of shared CPU last level cache
> to particular domain vcpu or a list of vcpus and monitoring the
> usage of cache, or the task of allocating a mount of memory
> bandwidth to specify domain vcpu(s).
> 
> This series is to introduce the support of MBM.
> 
> Basically the interfaces are:
> 
> ** Identify host capability **
> 
> Similar to identify the host capability of CMT, it could be gotten
> through the result of 'virsh capabilities', if following elements
> are found, then MBM is supported:
> 
> 
>   
> 
> 
>   
> 
> 
> 'mbm_total_bytes' means supporting to report the memory bandwidth
> used by the vcpu(s) of specific monitor on all CPU sockets.
> 
> 'mbm_local_bytes' means supporting to report the memory bandwidth
> used by vcpu(s) that is passing through local CPU socket.
> 
> ** Create monitor group**
> 
> The monitor group for specific domain vcpus, for example vcpu 0-4,
> is defined in domain configuration file, in such kind of way:
> 
>   
> 
>   
> 
>   
> 
> ** Report memory usage **
> 
> Introduced an option '--memory' against 'virsh domstats' command
> to show the memory bandwidth usage in such way:
> (also very similar to the format of CMT result.)
> 
> # virsh domstats --memory
> 
> Domain: 'libvirt-vm'
> memory.bandwidth.monitor.count=4
> memory.bandwidth.monitor.0.name=vcpus_0-4
> memory.bandwidth.monitor.0.vcpus=0-4
> memory.bandwidth.monitor.0.node.count=2
> memory.bandwidth.monitor.0.node.0.id=0
> memory.bandwidth.monitor.0.node.0.bytes.total=14201651200
> memory.bandwidth.monitor.0.node.0.bytes.local=7369809920
> memory.bandwidth.monitor.0.node.1.id=1
> memory.bandwidth.monitor.0.node.1.bytes.total=188897640448
> memory.bandwidth.monitor.0.node.1.bytes.local=170044047360
> 
> 
> Huaqiang (5):
>   util, resctrl: using 64bit interface instead of 32bit for counters
>   conf: showing cache/memoryBW monitor features in capabilities
>   cachetune schema: a looser check for the order of  and
>  element
>   conf: Parse dommon configure file for memorytune monitors
>   virsh: show memoryBW info in 'virsh domstats' command

I've pushed patches 2, 3, & 4, so you only need update 1 & 5 and resend
those two.



Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



Re: [libvirt] [PATCH 5/5] virsh: show memoryBW info in 'virsh domstats' command

2019-12-13 Thread Daniel P . Berrangé
On Thu, Nov 14, 2019 at 01:08:23AM +0800, Wang Huaqiang wrote:
> From: Huaqiang 
> 
> Introduce an option '--memory' for showing memory related
> information. The memory bandwidth infomatio is listed as:
> 
> Domain: 'libvirt-vm'
>   memory.bandwidth.monitor.count=4
>   memory.bandwidth.monitor.0.name=vcpus_0-4
>   memory.bandwidth.monitor.0.vcpus=0-4
>   memory.bandwidth.monitor.0.node.count=2
>   memory.bandwidth.monitor.0.node.0.id=0
>   memory.bandwidth.monitor.0.node.0.bytes.total=10208067584
>   memory.bandwidth.monitor.0.node.0.bytes.local=4807114752
>   memory.bandwidth.monitor.0.node.1.id=1
>   memory.bandwidth.monitor.0.node.1.bytes.total=8693735424
>   memory.bandwidth.monitor.0.node.1.bytes.local=5850161152
>   memory.bandwidth.monitor.1.name=vcpus_7
>   memory.bandwidth.monitor.1.vcpus=7
>   memory.bandwidth.monitor.1.node.count=2
>   memory.bandwidth.monitor.1.node.0.id=0
>   memory.bandwidth.monitor.1.node.0.bytes.total=853811200
>   memory.bandwidth.monitor.1.node.0.bytes.local=290701312
>   memory.bandwidth.monitor.1.node.1.id=1
>   memory.bandwidth.monitor.1.node.1.bytes.total=406044672
>   memory.bandwidth.monitor.1.node.1.bytes.local=229425152
> 
> Signed-off-by: Huaqiang 
> ---
>  include/libvirt/libvirt-domain.h |  1 +
>  src/libvirt-domain.c | 21 +++
>  src/qemu/qemu_driver.c   | 99 
>  tools/virsh-domain-monitor.c |  7 +++
>  tools/virsh.pod  | 23 +++-

Unfortunately this doesn't apply since I converted the manpages
from POD to RST.

Can you resend with update to docs/manpages/virsh.rst instead

>  5 files changed, 149 insertions(+), 2 deletions(-)
> 
> diff --git a/include/libvirt/libvirt-domain.h 
> b/include/libvirt/libvirt-domain.h
> index 22277b0a84..2b621ff162 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -2146,6 +2146,7 @@ typedef enum {
>  VIR_DOMAIN_STATS_BLOCK = (1 << 5), /* return domain block info */
>  VIR_DOMAIN_STATS_PERF = (1 << 6), /* return domain perf event info */
>  VIR_DOMAIN_STATS_IOTHREAD = (1 << 7), /* return iothread poll info */
> +VIR_DOMAIN_STATS_MEMORY= (1 << 8), /* return domain memory info */

Nitpick, whitespace before '='

>  } virDomainStatsTypes;

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



Re: [libvirt] [PATCH 2/2] news: Document init scripts

2019-12-13 Thread Daniel P . Berrangé
On Tue, Nov 26, 2019 at 03:46:12PM +0100, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik 
> ---
>  docs/news.xml | 11 +++
>  1 file changed, 11 insertions(+)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH 1/2] configure: Provide OpenRC scripts for sub-daemons

2019-12-13 Thread Daniel P . Berrangé
On Tue, Nov 26, 2019 at 03:46:11PM +0100, Michal Privoznik wrote:
> There is plenty of distributions that haven't switched to
> systemd nor they force their users to (Gentoo, Alpine Linux to
> name a few). With the daemon split merged their only option is to
> still use the monolithic daemon which will go away eventually.
> Provide init scripts for these distros too.

It will be unpleasant to not have socket activation of these daemons,
but such is life with old init systems i guess.

> For now, I'm not introducing config files which would correspond
> to the init files except for libvirtd and virtproxyd init scripts
> where it might be desirable to tweak the command line of
> corresponding daemons.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  m4/virt-init-script.m4   |  8 +++-
>  src/Makefile.am  | 56 +++-
>  src/interface/Makefile.inc.am| 11 ++
>  src/interface/virtinterfaced.init.in | 26 +
>  src/libxl/Makefile.inc.am| 10 +
>  src/libxl/virtxend.init.in   | 26 +
>  src/lxc/Makefile.inc.am  | 10 +
>  src/lxc/virtlxcd.init.in | 26 +
>  src/network/Makefile.inc.am  | 10 +
>  src/network/virtnetworkd.init.in | 26 +
>  src/node_device/Makefile.inc.am  | 11 ++
>  src/node_device/virtnodedevd.init.in | 26 +
>  src/nwfilter/Makefile.inc.am | 11 ++
>  src/nwfilter/virtnwfilterd.init.in   | 26 +
>  src/qemu/Makefile.inc.am | 10 +
>  src/qemu/virtqemud.init.in   | 26 +
>  src/remote/Makefile.inc.am   | 30 +++
>  src/remote/libvirtd.confd| 18 +
>  src/remote/libvirtd.init.in  | 29 ++
>  src/remote/virtproxyd.confd  | 10 +
>  src/remote/virtproxyd.init.in| 28 ++
>  src/secret/Makefile.inc.am   | 10 +
>  src/secret/virtsecretd.init.in   | 26 +
>  src/storage/Makefile.inc.am  | 10 +
>  src/storage/virtstoraged.init.in | 26 +
>  src/vbox/Makefile.inc.am | 10 +
>  src/vbox/virtvboxd.init.in   | 26 +
>  src/vz/Makefile.inc.am   | 10 +
>  src/vz/virtvzd.init.in   | 26 +
>  29 files changed, 576 insertions(+), 2 deletions(-)
>  create mode 100644 src/interface/virtinterfaced.init.in
>  create mode 100644 src/libxl/virtxend.init.in
>  create mode 100644 src/lxc/virtlxcd.init.in
>  create mode 100644 src/network/virtnetworkd.init.in
>  create mode 100644 src/node_device/virtnodedevd.init.in
>  create mode 100644 src/nwfilter/virtnwfilterd.init.in
>  create mode 100644 src/qemu/virtqemud.init.in
>  create mode 100644 src/remote/libvirtd.confd
>  create mode 100644 src/remote/libvirtd.init.in
>  create mode 100644 src/remote/virtproxyd.confd
>  create mode 100644 src/remote/virtproxyd.init.in
>  create mode 100644 src/secret/virtsecretd.init.in
>  create mode 100644 src/storage/virtstoraged.init.in
>  create mode 100644 src/vbox/virtvboxd.init.in
>  create mode 100644 src/vz/virtvzd.init.in

Reviewed-by: Daniel P. Berrangé 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH] virtio-blk: deprecate SCSI passthrough

2019-12-13 Thread Paolo Bonzini
On 13/12/19 16:10, Daniel P. Berrangé wrote:
> I don't think it really matters. QEMU is deprecating it with no
> seemless direct replacement, so I don't think libvirt needs to
> be concerned. The feature simply becomes unsupported.
> 
> At the very most we need to check if it exists before using it,
> but even that's just a nice to have which results in a slightly
> prettier error message.

Libvirt right now assumes that a QEMU without the scsi property defaults
to "on", but if the oldest supported QEMU version is 1.5.3 then it
already has the property.  So you can just give an error if there is no
scsi property and device='lun'.

Paolo


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

Re: [libvirt] [PATCH 4/5] conf: Parse dommon configure file for memorytune monitors

2019-12-13 Thread Daniel P . Berrangé
On Thu, Nov 14, 2019 at 01:08:22AM +0800, Wang Huaqiang wrote:
> From: Huaqiang 
> 
> Create memory bandwidth monitor.
> 
> Following domain configuration changes create two memory bandwidth
> monitors: one is monitoring the bandwidth consumed by vCPU 0,
> another is for vCPU 5.
> 
> ```
>
>  
>
>
>+   
>  
>+ 
>+   
>+ 
> 
>
> ```
> 
> Signed-off-by: Huaqiang 
> ---
>  docs/schemas/domaincommon.rng  | 23 +++
>  src/conf/domain_conf.c | 44 +-
>  tests/genericxml2xmlindata/memorytune.xml  |  5 +++
>  tests/genericxml2xmloutdata/memorytune.xml | 42 +
>  tests/genericxml2xmltest.c |  2 +-
>  5 files changed, 98 insertions(+), 18 deletions(-)
>  create mode 100644 tests/genericxml2xmloutdata/memorytune.xml

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH] virtio-blk: deprecate SCSI passthrough

2019-12-13 Thread Daniel P . Berrangé
On Fri, Dec 13, 2019 at 04:07:06PM +0100, Peter Krempa wrote:
> On Fri, Dec 13, 2019 at 15:56:08 +0100, Paolo Bonzini wrote:
> > On 13/12/19 15:46, Stefan Hajnoczi wrote:
> > > The Linux virtio_blk.ko guest driver is removing legacy SCSI passthrough
> > > support.  Deprecate this feature in QEMU too.
> > > 
> > > Signed-off-by: Stefan Hajnoczi 
> > > ---
> > >  qemu-deprecated.texi | 11 +++
> > >  1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> > > index 4b4b7425ac..ef94d497da 100644
> > > --- a/qemu-deprecated.texi
> > > +++ b/qemu-deprecated.texi
> > > @@ -285,6 +285,17 @@ spec you can use the ``-cpu 
> > > rv64gcsu,priv_spec=v1.9.1`` command line argument.
> > >  
> > >  @section Device options
> > >  
> > > +@subsection Emulated device options
> > > +
> > > +@subsubsection -device virtio-blk,scsi=on|off (since 5.0.0)
> > > +
> > > +The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  
> > > VIRTIO 1.0
> > > +and later do not support it because the virtio-scsi device was 
> > > introduced for
> > > +full SCSI support.  Use virtio-scsi instead when SCSI passthrough is 
> > > required.
> > > +
> > > +Note this also applies to ``-device virtio-blk-pci,scsi=on|off'', which 
> > > is an
> > > +alias.
> > > +
> > >  @subsection Block device options
> > >  
> > >  @subsubsection "backing": "" (since 2.12.0)
> > > 
> > 
> > Reviewed-by: Paolo Bonzini 
> 
> Libvirt still allows and exposes this configuration:
> 
> 
>   
>   
>   
>function='0x0'/>
> 
> 
> which results into the following command line:
> 
> -drive file=/dev/sdfake2,format=qcow2,if=none,id=drive-virtio-disk1 \
> -device virtio-blk-pci,scsi=on,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,\
> id=virtio-disk1
> 
> In this case I don't see any possibility how to fix it since it requires
> change of controller.

I don't think it really matters. QEMU is deprecating it with no
seemless direct replacement, so I don't think libvirt needs to
be concerned. The feature simply becomes unsupported.

At the very most we need to check if it exists before using it,
but even that's just a nice to have which results in a slightly
prettier error message.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



Re: [libvirt] [PATCH 3/5] cachetune schema: a looser check for the order of and element

2019-12-13 Thread Daniel P . Berrangé
On Thu, Nov 14, 2019 at 01:08:21AM +0800, Wang Huaqiang wrote:
> From: Huaqiang 
> 
> Originally, inside , it requires the  element to
> be in the position before , and following configuration is not
> permitted by schema, but it is better to let it be valid.
> 
>   
> 
>   
> ^
> |__ Not permitted originally because it is in the place
> before  element.
> 
>   
>   
> 
> ...
>   
> 
> And, let schema do more strict check by identifying following configuration to
> be invalid, due to  should contain at least one  or 
> 
> element.
> 
>   
> 
> ^
> |__ a  SHOULD contain at least one  or 
> 
> 
> ...
>   
> 
> Signed-off-by: Huaqiang 
> ---
>  docs/schemas/domaincommon.rng | 68 +++
>  tests/genericxml2xmlindata/cachetune.xml  |  1 +
>  tests/genericxml2xmloutdata/cachetune.xml | 34 
>  tests/genericxml2xmltest.c|  2 +-
>  4 files changed, 70 insertions(+), 35 deletions(-)
>  create mode 100644 tests/genericxml2xmloutdata/cachetune.xml

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH] virtio-blk: deprecate SCSI passthrough

2019-12-13 Thread Peter Krempa
On Fri, Dec 13, 2019 at 15:56:08 +0100, Paolo Bonzini wrote:
> On 13/12/19 15:46, Stefan Hajnoczi wrote:
> > The Linux virtio_blk.ko guest driver is removing legacy SCSI passthrough
> > support.  Deprecate this feature in QEMU too.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  qemu-deprecated.texi | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> > index 4b4b7425ac..ef94d497da 100644
> > --- a/qemu-deprecated.texi
> > +++ b/qemu-deprecated.texi
> > @@ -285,6 +285,17 @@ spec you can use the ``-cpu 
> > rv64gcsu,priv_spec=v1.9.1`` command line argument.
> >  
> >  @section Device options
> >  
> > +@subsection Emulated device options
> > +
> > +@subsubsection -device virtio-blk,scsi=on|off (since 5.0.0)
> > +
> > +The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  
> > VIRTIO 1.0
> > +and later do not support it because the virtio-scsi device was introduced 
> > for
> > +full SCSI support.  Use virtio-scsi instead when SCSI passthrough is 
> > required.
> > +
> > +Note this also applies to ``-device virtio-blk-pci,scsi=on|off'', which is 
> > an
> > +alias.
> > +
> >  @subsection Block device options
> >  
> >  @subsubsection "backing": "" (since 2.12.0)
> > 
> 
> Reviewed-by: Paolo Bonzini 

Libvirt still allows and exposes this configuration:


  
  
  
  


which results into the following command line:

-drive file=/dev/sdfake2,format=qcow2,if=none,id=drive-virtio-disk1 \
-device virtio-blk-pci,scsi=on,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,\
id=virtio-disk1

In this case I don't see any possibility how to fix it since it requires
change of controller.

I don't think that we've also added interlocks for this with VIRTIO 1.0

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



Re: [libvirt] [PATCH 2/5] conf: showing cache/memoryBW monitor features in capabilities

2019-12-13 Thread Daniel P . Berrangé
On Thu, Nov 14, 2019 at 01:08:20AM +0800, Wang Huaqiang wrote:
> From: Huaqiang 
> 
> We learned that the hardware features of CAT, CMT, MBA and MBM
> are orthogonal ones, if CAT or MBA is not supported in system,
> but CMT or MBM are supported, then the cache monitor or
> memoryBW monitor features may not be correctly displayed in
> host capabilities through command 'virsh capabilites'.
> 
> Showing the cache/memoryBW monitor capabilities even there is
> no support of cache allocation or memoryBW allocation features.
> 
> Signed-off-by: Huaqiang 
> ---
>  src/conf/capabilities.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH] virtio-blk: deprecate SCSI passthrough

2019-12-13 Thread Christoph Hellwig
On Fri, Dec 13, 2019 at 02:46:26PM +, Stefan Hajnoczi wrote:
> The Linux virtio_blk.ko guest driver is removing legacy SCSI passthrough
> support.  Deprecate this feature in QEMU too.
> 
> Signed-off-by: Stefan Hajnoczi 

Fine with me as the original author:

Reviewed-by: Christoph Hellwig 


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



Re: [libvirt] [PATCH 1/5] util, resctrl: using 64bit interface instead of 32bit for counters

2019-12-13 Thread Daniel P . Berrangé
On Thu, Nov 14, 2019 at 01:08:19AM +0800, Wang Huaqiang wrote:
> From: Huaqiang 
> 
> The underlying resctrl monitoring is actually using 64 bit counters,
> not the 32bit one. Correct this by using 64bit interfaces.
> 
> Signed-off-by: Huaqiang 
> ---
>  src/qemu/qemu_driver.c |  4 ++--
>  src/util/virfile.c | 40 
>  src/util/virfile.h |  2 ++
>  src/util/virresctrl.c  |  6 +++---
>  src/util/virresctrl.h  |  2 +-
>  5 files changed, 48 insertions(+), 6 deletions(-)
> 
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index f4ff2ba292..e396358871 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -20587,8 +20587,8 @@ qemuDomainGetStatsCpuCache(virQEMUDriverPtr driver,
>   
> "cpu.cache.monitor.%zu.bank.%zu.id", i, j) < 0)
>  goto cleanup;
>  
> -if (virTypedParamListAddUInt(params, 
> resdata[i]->stats[j]->vals[0],
> - 
> "cpu.cache.monitor.%zu.bank.%zu.bytes", i, j) < 0)
> +if (virTypedParamListAddULLong(params, 
> resdata[i]->stats[j]->vals[0],
> +   
> "cpu.cache.monitor.%zu.bank.%zu.bytes", i, j) < 0)
>  goto cleanup;
>  }
>  }

Urgh, we cannot do this, as it changes API semantics for applications.

Apps are expecting this field to be encoded as UInt & so the change
will break their decoding.

Is this 32 vs 64-bit difference actually a problem in the real world.

eg can the 32-bit value genuinely overflow in real deployments of
this feature ?


If not, then we should not change this at all.



If we do need to change this though, the only option is to leave the
current field unchanged, and document that it can be truncated.

Then introduce a new field with a different name

eg   cpu.cache.monitor.%zu.bank.%zu.bytes64

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



Re: [libvirt] [PATCH] virtio-blk: deprecate SCSI passthrough

2019-12-13 Thread Paolo Bonzini
On 13/12/19 15:46, Stefan Hajnoczi wrote:
> The Linux virtio_blk.ko guest driver is removing legacy SCSI passthrough
> support.  Deprecate this feature in QEMU too.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  qemu-deprecated.texi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 4b4b7425ac..ef94d497da 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -285,6 +285,17 @@ spec you can use the ``-cpu rv64gcsu,priv_spec=v1.9.1`` 
> command line argument.
>  
>  @section Device options
>  
> +@subsection Emulated device options
> +
> +@subsubsection -device virtio-blk,scsi=on|off (since 5.0.0)
> +
> +The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  VIRTIO 
> 1.0
> +and later do not support it because the virtio-scsi device was introduced for
> +full SCSI support.  Use virtio-scsi instead when SCSI passthrough is 
> required.
> +
> +Note this also applies to ``-device virtio-blk-pci,scsi=on|off'', which is an
> +alias.
> +
>  @subsection Block device options
>  
>  @subsubsection "backing": "" (since 2.12.0)
> 

Reviewed-by: Paolo Bonzini 

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



[libvirt] [PATCH] virtio-blk: deprecate SCSI passthrough

2019-12-13 Thread Stefan Hajnoczi
The Linux virtio_blk.ko guest driver is removing legacy SCSI passthrough
support.  Deprecate this feature in QEMU too.

Signed-off-by: Stefan Hajnoczi 
---
 qemu-deprecated.texi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 4b4b7425ac..ef94d497da 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -285,6 +285,17 @@ spec you can use the ``-cpu rv64gcsu,priv_spec=v1.9.1`` 
command line argument.
 
 @section Device options
 
+@subsection Emulated device options
+
+@subsubsection -device virtio-blk,scsi=on|off (since 5.0.0)
+
+The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  VIRTIO 1.0
+and later do not support it because the virtio-scsi device was introduced for
+full SCSI support.  Use virtio-scsi instead when SCSI passthrough is required.
+
+Note this also applies to ``-device virtio-blk-pci,scsi=on|off'', which is an
+alias.
+
 @subsection Block device options
 
 @subsubsection "backing": "" (since 2.12.0)
-- 
2.23.0

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



[libvirt] [jenkins-ci PATCH v3 0/7] Add support for gtk-vnc builds

2019-12-13 Thread Daniel P . Berrangé
Support gtk-vnc and make virt-viewer depend on it

I sent this months ago & forgot to push it. Re-sending just in
case something has invalidated any patches. I've at least added
the newer distros

This time with gdk-pixbuf added and previous suggested fixes

Daniel P. Berrangé (7):
  mappings: add libgcrypt
  mappings: add PulseAudio
  mappings: add gdk-pixbuf
  guests: pull in deps for gtk-vnc project
  projects: add gtk-vnc project
  projects: make virt-viewer depend on gtk-vnc jobs
  mappings: remove gtk-vnc2

 guests/host_vars/libvirt-centos-7/main.yml|  1 +
 guests/host_vars/libvirt-centos-8/main.yml|  1 +
 guests/host_vars/libvirt-debian-10/main.yml   |  1 +
 guests/host_vars/libvirt-debian-9/main.yml|  1 +
 guests/host_vars/libvirt-debian-sid/main.yml  |  1 +
 guests/host_vars/libvirt-fedora-30/main.yml   |  3 ++
 guests/host_vars/libvirt-fedora-31/main.yml   |  1 +
 .../host_vars/libvirt-fedora-rawhide/main.yml |  1 +
 guests/host_vars/libvirt-freebsd-11/main.yml  |  1 +
 guests/host_vars/libvirt-freebsd-12/main.yml  |  1 +
 .../libvirt-freebsd-current/main.yml  |  1 +
 guests/host_vars/libvirt-ubuntu-1604/main.yml |  1 +
 guests/host_vars/libvirt-ubuntu-1804/main.yml |  1 +
 guests/playbooks/build/jobs/defaults.yml  |  3 ++
 .../build/projects/gtk-vnc+mingw32.yml| 12 ++
 .../build/projects/gtk-vnc+mingw64.yml| 12 ++
 guests/playbooks/build/projects/gtk-vnc.yml   | 19 +
 guests/vars/mappings.yml  | 42 +--
 guests/vars/projects/gtk-vnc+mingw32.yml  |  7 
 guests/vars/projects/gtk-vnc+mingw64.yml  |  7 
 guests/vars/projects/gtk-vnc.yml  | 12 ++
 guests/vars/projects/virt-viewer+mingw32.yml  |  1 -
 guests/vars/projects/virt-viewer+mingw64.yml  |  1 -
 guests/vars/projects/virt-viewer.yml  |  1 -
 jenkins/jobs/defaults.yaml|  3 ++
 jenkins/projects/gtk-vnc+mingw32.yaml | 12 ++
 jenkins/projects/gtk-vnc+mingw64.yaml | 12 ++
 jenkins/projects/gtk-vnc.yaml | 15 +++
 jenkins/projects/virt-viewer+mingw32.yaml |  4 +-
 jenkins/projects/virt-viewer+mingw64.yaml |  4 +-
 jenkins/projects/virt-viewer.yaml |  4 +-
 31 files changed, 167 insertions(+), 19 deletions(-)
 create mode 100644 guests/playbooks/build/projects/gtk-vnc+mingw32.yml
 create mode 100644 guests/playbooks/build/projects/gtk-vnc+mingw64.yml
 create mode 100644 guests/playbooks/build/projects/gtk-vnc.yml
 create mode 100644 guests/vars/projects/gtk-vnc+mingw32.yml
 create mode 100644 guests/vars/projects/gtk-vnc+mingw64.yml
 create mode 100644 guests/vars/projects/gtk-vnc.yml
 create mode 100644 jenkins/projects/gtk-vnc+mingw32.yaml
 create mode 100644 jenkins/projects/gtk-vnc+mingw64.yaml
 create mode 100644 jenkins/projects/gtk-vnc.yaml

-- 
2.23.0

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

[libvirt] [jenkins-ci PATCH v3 7/7] mappings: remove gtk-vnc2

2019-12-13 Thread Daniel P . Berrangé
Reviewed-by: Andrea Bolognani 
Signed-off-by: Daniel P. Berrangé 
---
 guests/vars/mappings.yml | 13 -
 1 file changed, 13 deletions(-)

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 15c2b70..6ff4237 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -245,13 +245,6 @@ mappings:
 default: gtk-update-icon-cache
 Ubuntu1604: libgtk2.0-bin
 
-  gtk-vnc2:
-deb: libgtk-vnc-2.0-dev
-pkg: gtk-vnc
-rpm: gtk-vnc2-devel
-CentOS8:
-cross-policy-deb: foreign
-
   hal:
 FreeBSD: hal
 
@@ -532,9 +525,6 @@ mappings:
   mingw32-gtk3:
 Fedora: mingw32-gtk3
 
-  mingw32-gtk-vnc2:
-Fedora: mingw32-gtk-vnc2
-
   mingw32-json-glib:
 Fedora: mingw32-json-glib
 
@@ -619,9 +609,6 @@ mappings:
   mingw64-gtk3:
 Fedora: mingw64-gtk3
 
-  mingw64-gtk-vnc2:
-Fedora: mingw64-gtk-vnc2
-
   mingw64-json-glib:
 Fedora: mingw64-json-glib
 
-- 
2.23.0

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

[libvirt] [jenkins-ci PATCH v3 1/7] mappings: add libgcrypt

2019-12-13 Thread Daniel P . Berrangé
Reviewed-by: Andrea Bolognani 
Signed-off-by: Daniel P. Berrangé 
---
 guests/vars/mappings.yml | 12 
 1 file changed, 12 insertions(+)

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index ef4e17a..fb99560 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -336,6 +336,12 @@ mappings:
 OpenSUSE: dbus-1-devel
 cross-policy-deb: foreign
 
+  libgcrypt:
+deb: libgcrypt20-dev
+pkg: libgcrypt
+rpm: libgcrypt-devel
+cross-policy-deb: foreign
+
   libgovirt:
 rpm: libgovirt-devel
 CentOS8:
@@ -526,6 +532,9 @@ mappings:
   mingw32-libarchive:
 Fedora: mingw32-libarchive
 
+  mingw32-libgcrypt:
+Fedora: mingw32-libgcrypt
+
   mingw32-libgovirt:
 Fedora: mingw32-libgovirt
 
@@ -607,6 +616,9 @@ mappings:
   mingw64-libarchive:
 Fedora: mingw64-libarchive
 
+  mingw64-libgcrypt:
+Fedora: mingw64-libgcrypt
+
   mingw64-libgovirt:
 Fedora: mingw64-libgovirt
 
-- 
2.23.0

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

[libvirt] [jenkins-ci PATCH v3 3/7] mappings: add gdk-pixbuf

2019-12-13 Thread Daniel P . Berrangé
Signed-off-by: Daniel P. Berrangé 
---
 guests/vars/mappings.yml | 12 
 1 file changed, 12 insertions(+)

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 96d37bd..15c2b70 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -177,6 +177,12 @@ mappings:
   gdb:
 default: gdb
 
+  gdk-pixbuf:
+rpm: gdk-pixbuf2-devel
+deb: libgdk-pixbuf2.0-dev
+pkg: gdk-pixbuf2
+cross-policy-deb: foreign
+
   gettext:
 default: gettext
 
@@ -502,6 +508,9 @@ mappings:
   mingw32-gcc:
 Fedora: mingw32-gcc
 
+  mingw32-gdk-pixbuf:
+Fedora: mingw32-gdk-pixbuf
+
   mingw32-gettext:
 Fedora: mingw32-gettext
 
@@ -586,6 +595,9 @@ mappings:
   mingw64-gcc:
 Fedora: mingw64-gcc
 
+  mingw64-gdk-pixbuf:
+Fedora: mingw64-gdk-pixbuf
+
   mingw64-gettext:
 Fedora: mingw64-gettext
 
-- 
2.23.0

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

[libvirt] [jenkins-ci PATCH v3 2/7] mappings: add PulseAudio

2019-12-13 Thread Daniel P . Berrangé
Reviewed-by: Andrea Bolognani 
Signed-off-by: Daniel P. Berrangé 
---
 guests/vars/mappings.yml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index fb99560..96d37bd 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -833,6 +833,11 @@ mappings:
 default: polkit
 deb: policykit-1
 
+  pulseaudio:
+deb: libpulse-dev
+rpm: pulseaudio-libs-devel
+cross-policy-deb: foreign
+
   python3-docutils:
 default: python3-docutils
 CentOS7: python36-docutils
-- 
2.23.0

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

[libvirt] [jenkins-ci PATCH v3 6/7] projects: make virt-viewer depend on gtk-vnc jobs

2019-12-13 Thread Daniel P . Berrangé
Reviewed-by: Andrea Bolognani 
Signed-off-by: Daniel P. Berrangé 
---
 guests/playbooks/build/jobs/defaults.yml | 1 +
 guests/vars/projects/virt-viewer+mingw32.yml | 1 -
 guests/vars/projects/virt-viewer+mingw64.yml | 1 -
 guests/vars/projects/virt-viewer.yml | 1 -
 jenkins/jobs/defaults.yaml   | 1 +
 jenkins/projects/virt-viewer+mingw32.yaml| 4 +++-
 jenkins/projects/virt-viewer+mingw64.yaml| 4 +++-
 jenkins/projects/virt-viewer.yaml| 4 +++-
 8 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/guests/playbooks/build/jobs/defaults.yml 
b/guests/playbooks/build/jobs/defaults.yml
index 5cbc440..65dee78 100644
--- a/guests/playbooks/build/jobs/defaults.yml
+++ b/guests/playbooks/build/jobs/defaults.yml
@@ -32,6 +32,7 @@ strip_buildrequires: |
   sed -i -e 's/BuildRequires: *libvirt.*//' *.spec*
   sed -i -e 's/BuildRequires: *osinfo-db.*//' *.spec*
   sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec*
+  sed -i -e 's/BuildRequires: *pkgconfig(gtk-vnc-.*).*//' *.spec*
   sed -i -e 's/BuildRequires: *pkgconfig(libvirt.*).*//' *.spec*
 mingw32_local_env: |
   export VIRT_PREFIX="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw"
diff --git a/guests/vars/projects/virt-viewer+mingw32.yml 
b/guests/vars/projects/virt-viewer+mingw32.yml
index 2b914c3..608d722 100644
--- a/guests/vars/projects/virt-viewer+mingw32.yml
+++ b/guests/vars/projects/virt-viewer+mingw32.yml
@@ -6,7 +6,6 @@ packages:
   - mingw32-gstreamer1-plugins-bad-free
   - mingw32-gstreamer1-plugins-good
   - mingw32-gtk3
-  - mingw32-gtk-vnc2
   - mingw32-libgovirt
   - mingw32-libusbx
   - mingw32-rest
diff --git a/guests/vars/projects/virt-viewer+mingw64.yml 
b/guests/vars/projects/virt-viewer+mingw64.yml
index 6b42a7f..3aa5893 100644
--- a/guests/vars/projects/virt-viewer+mingw64.yml
+++ b/guests/vars/projects/virt-viewer+mingw64.yml
@@ -6,7 +6,6 @@ packages:
   - mingw64-gstreamer1-plugins-bad-free
   - mingw64-gstreamer1-plugins-good
   - mingw64-gtk3
-  - mingw64-gtk-vnc2
   - mingw64-libgovirt
   - mingw64-libusbx
   - mingw64-rest
diff --git a/guests/vars/projects/virt-viewer.yml 
b/guests/vars/projects/virt-viewer.yml
index c03d50b..fe754cb 100644
--- a/guests/vars/projects/virt-viewer.yml
+++ b/guests/vars/projects/virt-viewer.yml
@@ -1,7 +1,6 @@
 ---
 packages:
   - glib2
-  - gtk-vnc2
   - gtk3
   - libgovirt
   - libxml2
diff --git a/jenkins/jobs/defaults.yaml b/jenkins/jobs/defaults.yaml
index 2d9ffef..ec429ed 100644
--- a/jenkins/jobs/defaults.yaml
+++ b/jenkins/jobs/defaults.yaml
@@ -28,6 +28,7 @@
   sed -i -e 's/BuildRequires: *libvirt.*//' *.spec*
   sed -i -e 's/BuildRequires: *osinfo-db.*//' *.spec*
   sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec*
+  sed -i -e 's/BuildRequires: *pkgconfig(gtk-vnc-.*).*//' *.spec*
   sed -i -e 's/BuildRequires: *pkgconfig(libvirt.*).*//' *.spec*
 mingw32_local_env: |
   export VIRT_PREFIX="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw"
diff --git a/jenkins/projects/virt-viewer+mingw32.yaml 
b/jenkins/projects/virt-viewer+mingw32.yaml
index c9c74ea..7d4738a 100644
--- a/jenkins/projects/virt-viewer+mingw32.yaml
+++ b/jenkins/projects/virt-viewer+mingw32.yaml
@@ -7,6 +7,8 @@
 git_url: '{git_urls[virt-viewer][default]}'
 jobs:
   - autotools-build-job:
-  parent_jobs: 'libvirt-glib+mingw32-build'
+  parent_jobs:
+- 'libvirt-glib+mingw32-build'
+- 'gtk-vnc+mingw32-build'
   local_env: '{mingw32_local_env}'
   autogen_args: '{mingw32_autogen_args}'
diff --git a/jenkins/projects/virt-viewer+mingw64.yaml 
b/jenkins/projects/virt-viewer+mingw64.yaml
index c3b570f..dfbd70d 100644
--- a/jenkins/projects/virt-viewer+mingw64.yaml
+++ b/jenkins/projects/virt-viewer+mingw64.yaml
@@ -7,6 +7,8 @@
 git_url: '{git_urls[virt-viewer][default]}'
 jobs:
   - autotools-build-job:
-  parent_jobs: 'libvirt-glib+mingw64-build'
+  parent_jobs:
+- 'libvirt-glib+mingw64-build'
+- 'gtk-vnc+mingw64-build'
   local_env: '{mingw64_local_env}'
   autogen_args: '{mingw64_autogen_args}'
diff --git a/jenkins/projects/virt-viewer.yaml 
b/jenkins/projects/virt-viewer.yaml
index 6469b9f..123f95e 100644
--- a/jenkins/projects/virt-viewer.yaml
+++ b/jenkins/projects/virt-viewer.yaml
@@ -7,7 +7,9 @@
 git_url: '{git_urls[virt-viewer][default]}'
 jobs:
   - autotools-build-job:
-  parent_jobs: 'libvirt-glib-build'
+  parent_jobs:
+- 'libvirt-glib-build'
+- 'gtk-vnc-build'
   - autotools-syntax-check-job:
   parent_jobs: 'virt-viewer-build'
   - autotools-check-job:
-- 
2.23.0

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

[libvirt] [jenkins-ci PATCH v3 5/7] projects: add gtk-vnc project

2019-12-13 Thread Daniel P . Berrangé
Signed-off-by: Daniel P. Berrangé 
---
 guests/playbooks/build/jobs/defaults.yml  |  2 ++
 .../build/projects/gtk-vnc+mingw32.yml| 12 
 .../build/projects/gtk-vnc+mingw64.yml| 12 
 guests/playbooks/build/projects/gtk-vnc.yml   | 19 +++
 jenkins/jobs/defaults.yaml|  2 ++
 jenkins/projects/gtk-vnc+mingw32.yaml | 12 
 jenkins/projects/gtk-vnc+mingw64.yaml | 12 
 jenkins/projects/gtk-vnc.yaml | 15 +++
 8 files changed, 86 insertions(+)
 create mode 100644 guests/playbooks/build/projects/gtk-vnc+mingw32.yml
 create mode 100644 guests/playbooks/build/projects/gtk-vnc+mingw64.yml
 create mode 100644 guests/playbooks/build/projects/gtk-vnc.yml
 create mode 100644 jenkins/projects/gtk-vnc+mingw32.yaml
 create mode 100644 jenkins/projects/gtk-vnc+mingw64.yaml
 create mode 100644 jenkins/projects/gtk-vnc.yaml

diff --git a/guests/playbooks/build/jobs/defaults.yml 
b/guests/playbooks/build/jobs/defaults.yml
index 5e4ec03..5cbc440 100644
--- a/guests/playbooks/build/jobs/defaults.yml
+++ b/guests/playbooks/build/jobs/defaults.yml
@@ -46,6 +46,8 @@ mingw64_local_env: |
 mingw64_autogen_args: --host=x86_64-w64-mingw32
 mingw64_meson_args: --cross-file=/usr/share/mingw/toolchain-mingw64.meson
 git_urls:
+  gtk-vnc:
+default: https://gitlab.gnome.org/GNOME/gtk-vnc.git
   libosinfo:
 default: https://gitlab.com/libosinfo/libosinfo.git
   libvirt-cim:
diff --git a/guests/playbooks/build/projects/gtk-vnc+mingw32.yml 
b/guests/playbooks/build/projects/gtk-vnc+mingw32.yml
new file mode 100644
index 000..2328a1d
--- /dev/null
+++ b/guests/playbooks/build/projects/gtk-vnc+mingw32.yml
@@ -0,0 +1,12 @@
+---
+- set_fact:
+name: gtk-vnc+mingw32
+machines: '{{ mingw_machines }}'
+archive_format: xz
+git_url: '{{ git_urls["gtk-vnc"][git_remote] }}'
+
+- include: '{{ playbook_base }}/jobs/prepare.yml'
+- include: '{{ playbook_base }}/jobs/meson-build-job.yml'
+  vars:
+local_env: '{{ mingw32_local_env }}'
+meson_args: '{{ mingw32_meson_args }}'
diff --git a/guests/playbooks/build/projects/gtk-vnc+mingw64.yml 
b/guests/playbooks/build/projects/gtk-vnc+mingw64.yml
new file mode 100644
index 000..8644f4c
--- /dev/null
+++ b/guests/playbooks/build/projects/gtk-vnc+mingw64.yml
@@ -0,0 +1,12 @@
+---
+- set_fact:
+name: gtk-vnc+mingw64
+machines: '{{ mingw_machines }}'
+archive_format: xz
+git_url: '{{ git_urls["gtk-vnc"][git_remote] }}'
+
+- include: '{{ playbook_base }}/jobs/prepare.yml'
+- include: '{{ playbook_base }}/jobs/meson-build-job.yml'
+  vars:
+local_env: '{{ mingw64_local_env }}'
+meson_args: '{{ mingw32_meson_args }}'
diff --git a/guests/playbooks/build/projects/gtk-vnc.yml 
b/guests/playbooks/build/projects/gtk-vnc.yml
new file mode 100644
index 000..260cf71
--- /dev/null
+++ b/guests/playbooks/build/projects/gtk-vnc.yml
@@ -0,0 +1,19 @@
+---
+- set_fact:
+name: gtk-vnc
+machines: '{{ all_machines }}'
+archive_format: xz
+git_url: '{{ git_urls["gtk-vnc"][git_remote] }}'
+
+- include: '{{ playbook_base }}/jobs/prepare.yml'
+- include: '{{ playbook_base }}/jobs/meson-build-job.yml'
+- include: '{{ playbook_base }}/jobs/meson-check-job.yml'
+- include: '{{ playbook_base }}/jobs/meson-rpm-job.yml'
+  vars:
+# RPM build is still not possible on CentOS7 as it does not
+# have the needed RPM macros for meson.
+machines:
+  - libvirt-centos-8
+  - libvirt-fedora-30
+  - libvirt-fedora-31
+  - libvirt-fedora-rawhide
diff --git a/jenkins/jobs/defaults.yaml b/jenkins/jobs/defaults.yaml
index 676ecbf..2d9ffef 100644
--- a/jenkins/jobs/defaults.yaml
+++ b/jenkins/jobs/defaults.yaml
@@ -42,6 +42,8 @@
 mingw64_autogen_args: --host=x86_64-w64-mingw32
 mingw64_meson_args: --cross-file=/usr/share/mingw/toolchain-mingw64.meson
 git_urls:
+  gtk-vnc:
+default: https://gitlab.gnome.org/GNOME/gtk-vnc.git
   libosinfo:
 default: https://gitlab.com/libosinfo/libosinfo.git
   libvirt-cim:
diff --git a/jenkins/projects/gtk-vnc+mingw32.yaml 
b/jenkins/projects/gtk-vnc+mingw32.yaml
new file mode 100644
index 000..bfb12da
--- /dev/null
+++ b/jenkins/projects/gtk-vnc+mingw32.yaml
@@ -0,0 +1,12 @@
+---
+- project:
+name: gtk-vnc+mingw32
+machines: '{mingw_machines}'
+title: GTK-VNC MinGW (32-bit)
+archive_format: xz
+git_url: '{git_urls[gtk-vnc][default]}'
+jobs:
+  - meson-build-job:
+  parent_jobs:
+  local_env: '{mingw32_local_env}'
+  meson_args: '{mingw32_meson_args}'
diff --git a/jenkins/projects/gtk-vnc+mingw64.yaml 
b/jenkins/projects/gtk-vnc+mingw64.yaml
new file mode 100644
index 000..543958d
--- /dev/null
+++ b/jenkins/projects/gtk-vnc+mingw64.yaml
@@ -0,0 +1,12 @@
+---
+- project:
+name: gtk-vnc+mingw64
+machines: '{mingw_machines}'
+title: GTK-VNC MinGW (64-bit)
+

[libvirt] [jenkins-ci PATCH v3 4/7] guests: pull in deps for gtk-vnc project

2019-12-13 Thread Daniel P . Berrangé
Signed-off-by: Daniel P. Berrangé 
---
 guests/host_vars/libvirt-centos-7/main.yml|  1 +
 guests/host_vars/libvirt-centos-8/main.yml|  1 +
 guests/host_vars/libvirt-debian-10/main.yml   |  1 +
 guests/host_vars/libvirt-debian-9/main.yml|  1 +
 guests/host_vars/libvirt-debian-sid/main.yml  |  1 +
 guests/host_vars/libvirt-fedora-30/main.yml   |  3 +++
 guests/host_vars/libvirt-fedora-31/main.yml   |  1 +
 guests/host_vars/libvirt-fedora-rawhide/main.yml  |  1 +
 guests/host_vars/libvirt-freebsd-11/main.yml  |  1 +
 guests/host_vars/libvirt-freebsd-12/main.yml  |  1 +
 guests/host_vars/libvirt-freebsd-current/main.yml |  1 +
 guests/host_vars/libvirt-ubuntu-1604/main.yml |  1 +
 guests/host_vars/libvirt-ubuntu-1804/main.yml |  1 +
 guests/vars/projects/gtk-vnc+mingw32.yml  |  7 +++
 guests/vars/projects/gtk-vnc+mingw64.yml  |  7 +++
 guests/vars/projects/gtk-vnc.yml  | 12 
 16 files changed, 41 insertions(+)
 create mode 100644 guests/vars/projects/gtk-vnc+mingw32.yml
 create mode 100644 guests/vars/projects/gtk-vnc+mingw64.yml
 create mode 100644 guests/vars/projects/gtk-vnc.yml

diff --git a/guests/host_vars/libvirt-centos-7/main.yml 
b/guests/host_vars/libvirt-centos-7/main.yml
index e0579ad..becd297 100644
--- a/guests/host_vars/libvirt-centos-7/main.yml
+++ b/guests/host_vars/libvirt-centos-7/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-cim
diff --git a/guests/host_vars/libvirt-centos-8/main.yml 
b/guests/host_vars/libvirt-centos-8/main.yml
index aae2313..cb49e9c 100644
--- a/guests/host_vars/libvirt-centos-8/main.yml
+++ b/guests/host_vars/libvirt-centos-8/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-debian-10/main.yml 
b/guests/host_vars/libvirt-debian-10/main.yml
index 633f421..c5d0047 100644
--- a/guests/host_vars/libvirt-debian-10/main.yml
+++ b/guests/host_vars/libvirt-debian-10/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-debian-9/main.yml 
b/guests/host_vars/libvirt-debian-9/main.yml
index 6b685a4..3addcd4 100644
--- a/guests/host_vars/libvirt-debian-9/main.yml
+++ b/guests/host_vars/libvirt-debian-9/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-debian-sid/main.yml 
b/guests/host_vars/libvirt-debian-sid/main.yml
index 3808383..a60dd1b 100644
--- a/guests/host_vars/libvirt-debian-sid/main.yml
+++ b/guests/host_vars/libvirt-debian-sid/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-fedora-30/main.yml 
b/guests/host_vars/libvirt-fedora-30/main.yml
index e395f32..e4ad7ea 100644
--- a/guests/host_vars/libvirt-fedora-30/main.yml
+++ b/guests/host_vars/libvirt-fedora-30/main.yml
@@ -1,5 +1,8 @@
 ---
 projects:
+  - gtk-vnc
+  - gtk-vnc+mingw32
+  - gtk-vnc+mingw64
   - libosinfo
   - libosinfo+mingw32
   - libosinfo+mingw64
diff --git a/guests/host_vars/libvirt-fedora-31/main.yml 
b/guests/host_vars/libvirt-fedora-31/main.yml
index 5d9a1b5..e605873 100644
--- a/guests/host_vars/libvirt-fedora-31/main.yml
+++ b/guests/host_vars/libvirt-fedora-31/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-cim
diff --git a/guests/host_vars/libvirt-fedora-rawhide/main.yml 
b/guests/host_vars/libvirt-fedora-rawhide/main.yml
index fc39363..1a3338c 100644
--- a/guests/host_vars/libvirt-fedora-rawhide/main.yml
+++ b/guests/host_vars/libvirt-fedora-rawhide/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-cim
diff --git a/guests/host_vars/libvirt-freebsd-11/main.yml 
b/guests/host_vars/libvirt-freebsd-11/main.yml
index e9f6d03..2de64ef 100644
--- a/guests/host_vars/libvirt-freebsd-11/main.yml
+++ b/guests/host_vars/libvirt-freebsd-11/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-freebsd-12/main.yml 
b/guests/host_vars/libvirt-freebsd-12/main.yml
index ba3ba62..2e3b935 100644
--- a/guests/host_vars/libvirt-freebsd-12/main.yml
+++ b/guests/host_vars/libvirt-freebsd-12/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-freebsd-current/main.yml 
b/guests/host_vars/libvirt-freebsd-current/main.yml
index 74e1856..9b63d30 100644
--- a/guests/host_vars/libvirt-freebsd-current/main.yml
+++ b/guests/host_vars/libvirt-freebsd-current/main.yml
@@ -1,5 +1,6 @@
 ---
 projects:
+  - gtk-vnc
   - libosinfo
   - libvirt
   - libvirt-dbus
diff --git a/guests/host_vars/libvirt-ubuntu-1604/main.yml 
b/guests/host_vars/libvirt-ubuntu-1604/main.yml
index 

Re: [libvirt] [PATCH v3 26/30] qemu_monitor_text: Catch IOMMU/VFIO related errors in qemuMonitorTextAddDrive

2019-12-13 Thread Cole Robinson
On 12/12/19 4:19 AM, Michal Privoznik wrote:
> On 12/10/19 9:50 PM, Cole Robinson wrote:
>> On 12/2/19 9:26 AM, Michal Privoznik wrote:
>>> Because this is a HMP we're dealing with, there is nothing like
>>> class of reply message, so we have to do some string comparison
>>> to guess if the command fails. Well, with NVMe disks whole new
>>> class of errors comes to play because qemu needs to initialize
>>> IOMMU and VFIO for them. You can see all the messages it may
>>> produce in qemu_vfio_init_pci().
>>>
>>> Signed-off-by: Michal Privoznik 
>>> ---
>>>   src/qemu/qemu_monitor_text.c | 7 +++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c
>>> index 9054682d60..6948a5bf90 100644
>>> --- a/src/qemu/qemu_monitor_text.c
>>> +++ b/src/qemu/qemu_monitor_text.c
>>> @@ -75,6 +75,13 @@ int qemuMonitorTextAddDrive(qemuMonitorPtr mon,
>>>   goto cleanup;
>>>   }
>>>   +    if (strstr(reply, "IOMMU") ||
>>> +    strstr(reply, "VFIO")) {
>>> +    virReportError(VIR_ERR_OPERATION_FAILED, "%s",
>>> +   reply);
>>> +    goto cleanup;
>>> +    }
>>> +
>>>   ret = 0;
>>>      cleanup:
>>>
>>
>> For the code:
>>
>> Reviewed-by: Cole Robinson 
>>
>> Does the blockdev infrastructure have magic that turns the Props into a
>> drive string? I don't see any -drive examples in the test output
> 
> Blockdev usues -device + -blockdev pair and obsoletes -drive. For instance:
> 
> libvirt.git $ grep "\-drive" $(git grep -l "\-blockdev" --
> tests/qemuxml2argvdata/)
> 
> Neither of -blockdev files has -drive.

Right. I think my confusion is that this is a pre-blockdev/-drive code
path, but I didn't see any explicit -drive handling in the series, just
-blockdev. So either I 1) missed the -drive changes but in that case
there should probably be test output demoing -drive output here, or 2)
this feature is -blockdev only in which case this is dead code. Or some
other case that I'm missing :)

- Cole

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

Re: [libvirt] [PATCH RESEND 0/4] Add support for Hygon Dhyana CPU

2019-12-13 Thread Daniel P . Berrangé
On Thu, Dec 12, 2019 at 10:58:17AM +0800, Yingle Hou wrote:
> As a Joint Venture between AMD and Haiguang Information Technology Co., Ltd.,
> Hygon aims to provide x86 server processor in China market. The first
> generation processor Dhyana (family 18h) shares similar architecture with
> AMD family 17h.
> 
> As Dhyana support in QEMU already have been merged in qemu-4.1.0 [1], to add
> Dhyana support in libvirt, we have added a new Dhyana CPU model file
> x86_Dhyana.xml in cpu_map directory, and also we have added a series of
> Dhyana test files.
> 
> We have tested the patches on Hygon Dhyana machine with the result that it
> has successfully worked as expected.

Thanks for your contribution & apologies for the delay in reviewing
it. I've squashed patch 4 into patch 2 and merged this.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



Re: [libvirt] [PATCH RESEND 4/4] domaincapstest: Add CPU model Dhyana to QEMU

2019-12-13 Thread Daniel P . Berrangé
On Thu, Dec 12, 2019 at 10:58:21AM +0800, Yingle Hou wrote:
> Add CPU model Dhyana to QEMU 4.1.0 and QEMU 4.2.0 in tests/domaincapstest/.
> 
> Signed-off-by: Yingle Hou 
> ---
>  tests/domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 1 +
>  tests/domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 1 +
>  tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 1 +
>  tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 1 +
>  tests/domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 1 +
>  tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 1 +
>  6 files changed, 6 insertions(+)

Reviewed-by: Daniel P. Berrangé 


but this patch needs to be squashed into patch 2, so that 'make check'
succeeeds at every step.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH RESEND 3/4] cputest: Add CPUID data for Hygon Dhyana 7185 32-core Processor

2019-12-13 Thread Daniel P . Berrangé
On Thu, Dec 12, 2019 at 10:58:20AM +0800, Yingle Hou wrote:
> Add Hygon Dhyana CPU data test case related files.
> 
> Signed-off-by: Yingle Hou 
> ---
>  tests/cputest.c|1 +
>  ...86_64-cpuid-Hygon-C86-7185-32-core-disabled.xml |7 +
>  ...x86_64-cpuid-Hygon-C86-7185-32-core-enabled.xml |9 +
>  .../x86_64-cpuid-Hygon-C86-7185-32-core-guest.xml  |   16 +
>  .../x86_64-cpuid-Hygon-C86-7185-32-core-host.xml   |   17 +
>  .../x86_64-cpuid-Hygon-C86-7185-32-core-json.xml   |   12 +
>  .../x86_64-cpuid-Hygon-C86-7185-32-core.json   | 1631 
> 
>  .../x86_64-cpuid-Hygon-C86-7185-32-core.sig|4 +
>  .../x86_64-cpuid-Hygon-C86-7185-32-core.xml|   54 +
>  9 files changed, 1751 insertions(+)
>  create mode 100644 
> tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core-disabled.xml
>  create mode 100644 
> tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core-enabled.xml
>  create mode 100644 
> tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core-guest.xml
>  create mode 100644 
> tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core-host.xml
>  create mode 100644 
> tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core-json.xml
>  create mode 100644 tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core.json
>  create mode 100644 tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core.sig
>  create mode 100644 tests/cputestdata/x86_64-cpuid-Hygon-C86-7185-32-core.xml

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH RESEND 1/4] cpu: Remove the verification conditions of the model in the x86 signatures

2019-12-13 Thread Daniel P . Berrangé
On Thu, Dec 12, 2019 at 10:58:18AM +0800, Yingle Hou wrote:
> The x86ModelParseSignatures function makes an assumption that CPU signature
> model equals 0 as an invalid case. While in Hygon processor definition, A1
> version (model 0, stepping 1) is mass production version, to support Hygon
> Dhyana A1 version, we have removed CPU signature model zero checking 
> condition.
> 
> Signed-off-by: Yingle Hou 
> ---
>  src/cpu/cpu_x86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH] docs: remove link to virsh cmd ref & app dev guide

2019-12-13 Thread Ján Tomko

On Fri, Dec 13, 2019 at 10:06:31AM +, Daniel P. Berrangé wrote:

Both the application developer guide and virsh command
reference are unmaintained for best part of 8 years, and
so horrifically out of date. This does not give a good
impression to people reading the docs. Now that we are
publishing the man pages online, those are a better
doc to read for virsh.  We can also highlight the API
reference instead of the app dev guide.

The virsh command reference & app dev guide will
still exist on the web root, but will not be linked
to.


It might be worthwhile to delete them completely. Even though
they both have a DRAFT watermark everywhere, people might reach them
via search engines.



Signed-off-by: Daniel P. Berrangé 
---
docs/docs.html.in | 48 +--
1 file changed, 21 insertions(+), 27 deletions(-)



regardless of the suggestion above:
Reviewed-by: Ján Tomko 

Jano


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

[libvirt] [dockerfiles PATCH] Drop Dockerfile for mips cross-builds on Debian sid

2019-12-13 Thread Andrea Bolognani
The Debian project has dropped support for the architecture.

Signed-off-by: Andrea Bolognani 
---
Pushed under the Dockerfiles maintainance rule. Text diff below.

 buildenv-libvirt-debian-sid-cross-mips.zip | Bin 1010 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 buildenv-libvirt-debian-sid-cross-mips.zip

diff --git a/buildenv-libvirt-debian-sid-cross-mips.zip 
b/buildenv-libvirt-debian-sid-cross-mips.zip
deleted file mode 100644
index 287fa12..000
--- a/buildenv-libvirt-debian-sid-cross-mips.zip
+++ /dev/null
@@ -1,112 +0,0 @@
-FROM debian:sid
-
-RUN export DEBIAN_FRONTEND=noninteractive && \
-apt-get update && \
-apt-get dist-upgrade -y && \
-apt-get install --no-install-recommends -y \
-augeas-lenses \
-augeas-tools \
-autoconf \
-automake \
-autopoint \
-bash \
-bash-completion \
-ca-certificates \
-ccache \
-chrony \
-dnsmasq-base \
-dwarves \
-ebtables \
-flake8 \
-gcc \
-gdb \
-gettext \
-git \
-iproute2 \
-kmod \
-libc-dev-bin \
-libtool \
-libtool-bin \
-libxml2-utils \
-locales \
-lsof \
-lvm2 \
-make \
-meson \
-net-tools \
-nfs-common \
-ninja-build \
-numad \
-open-iscsi \
-parted \
-patch \
-perl \
-pkgconf \
-policykit-1 \
-python3 \
-python3-docutils \
-python3-setuptools \
-qemu-utils \
-radvd \
-screen \
-scrub \
-strace \
-sudo \
-vim \
-xsltproc \
-zfs-fuse && \
-apt-get autoremove -y && \
-apt-get autoclean -y && \
-sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \
-dpkg-reconfigure locales
-
-RUN export DEBIAN_FRONTEND=noninteractive && \
-dpkg --add-architecture mips && \
-apt-get update && \
-apt-get dist-upgrade -y && \
-apt-get install --no-install-recommends -y \
-gcc-mips-linux-gnu \
-libacl1-dev:mips \
-libapparmor-dev:mips \
-libattr1-dev:mips \
-libaudit-dev:mips \
-libavahi-client-dev:mips \
-libblkid-dev:mips \
-libc6-dev:mips \
-libcap-ng-dev:mips \
-libcurl4-gnutls-dev:mips \
-libdbus-1-dev:mips \
-libdevmapper-dev:mips \
-libfuse-dev:mips \
-libglib2.0-dev:mips \
-libglusterfs-dev:mips \
-libgnutls28-dev:mips \
-libiscsi-dev:mips \
-libncurses-dev:mips \
-libnl-3-dev:mips \
-libnl-route-3-dev:mips \
-libnuma-dev:mips \
-libparted-dev:mips \
-libpcap0.8-dev:mips \
-libpciaccess-dev:mips \
-librbd-dev:mips \
-libreadline-dev:mips \
-libsanlock-dev:mips \
-libsasl2-dev:mips \
-libselinux1-dev:mips \
-libssh-gcrypt-dev:mips \
-libssh2-1-dev:mips \
-libtirpc-dev:mips \
-libudev-dev:mips \
-libxml2-dev:mips \
-libyajl-dev:mips \
-xfslibs-dev:mips && \
-apt-get autoremove -y && \
-apt-get autoclean -y
-
-ENV LANG "en_US.UTF-8"
-
-ENV ABI "mips-linux-gnu"
-ENV CONFIGURE_OPTS "--host=mips-linux-gnu \
---target=mips-linux-gnu"
-ENV PKG_CONFIG_LIBDIR "/usr/lib/mips-linux-gnu/pkgconfig"

-- 
2.23.0

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



Re: [libvirt] [PATCH] gitlab: Move mips job to Debian 9

2019-12-13 Thread Daniel P . Berrangé
On Fri, Dec 13, 2019 at 12:59:18PM +0100, Andrea Bolognani wrote:
> Support for the mips architecture has been dropped from Debian
> sid. Move the mipsel job from Debian 9 to Debian sid at the same
> time to keep things balanced.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  .gitlab-ci.yml | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH 0/2] cpu_map: Introduce IA32_ARCH_CAPABILITIES MSR bits for TAA

2019-12-13 Thread Ján Tomko

On Fri, Dec 13, 2019 at 12:48:31PM +0100, Jiri Denemark wrote:

CVE-2019-11135

TAA_NO and TSX_CTRL are new IA32_ARCH_CAPABILITIES MSR bits related to
the TSX Asynchronous Abort (TAA) vulnerability. See [1] and [2] for
details about the issue and mitigations.

[1] 
https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort
[2] 
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html

Jiri Denemark (2):
 cpu_map: Add TAA_NO bit for IA32_ARCH_CAPABILITIES MSR
 cpu_map: Add TSX_CTRL bit for IA32_ARCH_CAPABILITIES MSR

src/cpu_map/x86_features.xml | 6 ++
1 file changed, 6 insertions(+)



Reviewed-by: Ján Tomko 

Jano


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

[libvirt] [PATCH] gitlab: Move mips job to Debian 9

2019-12-13 Thread Andrea Bolognani
Support for the mips architecture has been dropped from Debian
sid. Move the mipsel job from Debian 9 to Debian sid at the same
time to keep things balanced.

Signed-off-by: Andrea Bolognani 
---
 .gitlab-ci.yml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3915a37a90..ea49c6178b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -17,9 +17,9 @@ debian-9-cross-mips64el:
   <<: *job_definition
   image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mips64el:latest
 
-debian-9-cross-mipsel:
+debian-9-cross-mips:
   <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mipsel:latest
+  image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mips:latest
 
 debian-10-cross-aarch64:
   <<: *job_definition
@@ -41,6 +41,6 @@ debian-sid-cross-i686:
   <<: *job_definition
   image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-i686:latest
 
-debian-sid-cross-mips:
+debian-sid-cross-mipsel:
   <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-mips:latest
+  image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-mipsel:latest
-- 
2.23.0

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



[libvirt] [PATCH 2/2] cpu_map: Add TSX_CTRL bit for IA32_ARCH_CAPABILITIES MSR

2019-12-13 Thread Jiri Denemark
CVE-2019-11135

When TSX_CTRL bit of IA32_ARCH_CAPABILITIES MSR is set to 1, the CPU
supports IA32_TSX_CTRL MSR which can be used to disable and/or mask TSX.

Signed-off-by: Jiri Denemark 
---
 src/cpu_map/x86_features.xml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml
index d1180ed26d..b42b490160 100644
--- a/src/cpu_map/x86_features.xml
+++ b/src/cpu_map/x86_features.xml
@@ -502,6 +502,9 @@
   
 
   
+  
+
+  
   
 
   
-- 
2.24.1

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



[libvirt] [PATCH 1/2] cpu_map: Add TAA_NO bit for IA32_ARCH_CAPABILITIES MSR

2019-12-13 Thread Jiri Denemark
CVE-2019-11135

CPUs with TAA_NO bit of IA32_ARCH_CAPABILITIES MSR set to 1 are not
vulnerable to TSX Asynchronous Abort and passing this bit to a guest
may avoid unnecessary mitigations.

Signed-off-by: Jiri Denemark 
---
 src/cpu_map/x86_features.xml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml
index 2bed1e0372..d1180ed26d 100644
--- a/src/cpu_map/x86_features.xml
+++ b/src/cpu_map/x86_features.xml
@@ -502,4 +502,7 @@
   
 
   
+  
+
+  
 
-- 
2.24.1

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



[libvirt] [PATCH 0/2] cpu_map: Introduce IA32_ARCH_CAPABILITIES MSR bits for TAA

2019-12-13 Thread Jiri Denemark
CVE-2019-11135

TAA_NO and TSX_CTRL are new IA32_ARCH_CAPABILITIES MSR bits related to
the TSX Asynchronous Abort (TAA) vulnerability. See [1] and [2] for
details about the issue and mitigations.

[1] 
https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort
[2] 
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html

Jiri Denemark (2):
  cpu_map: Add TAA_NO bit for IA32_ARCH_CAPABILITIES MSR
  cpu_map: Add TSX_CTRL bit for IA32_ARCH_CAPABILITIES MSR

 src/cpu_map/x86_features.xml | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.24.1

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



Re: [libvirt] [PATCH RESEND 2/4] cpu: Add new Dhyana CPU model

2019-12-13 Thread Daniel P . Berrangé
On Thu, Dec 12, 2019 at 10:58:19AM +0800, Yingle Hou wrote:
> Add Hygon Dhyana CPU model to the processor model.
> 
> Signed-off-by: Yingle Hou 
> ---
>  src/cpu_map/Makefile.inc.am |  1 +
>  src/cpu_map/index.xml   |  3 ++
>  src/cpu_map/x86_Dhyana.xml  | 70 
> +
>  src/cpu_map/x86_vendors.xml |  1 +
>  4 files changed, 75 insertions(+)
>  create mode 100644 src/cpu_map/x86_Dhyana.xml

Reviewed-by: Daniel P. Berrangé 



Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[libvirt] 回复: [PATCH] qemu: snapshot: Fix libvirtd crash in snapshot-revert

2019-12-13 Thread Lin Ma


> -邮件原件-
> 发件人: Michal Privoznik 
> 发送时间: 2019年12月13日 17:30
> 收件人: Peter Krempa ; Lin Ma 
> 抄送: libvir-list@redhat.com
> 主题: Re: [libvirt] [PATCH] qemu: snapshot: Fix libvirtd crash in 
> snapshot-revert
> 
> On 12/13/19 8:55 AM, Peter Krempa wrote:
> > On Fri, Dec 13, 2019 at 15:47:36 +0800, Lin Ma wrote:
> >> When reverting a running domain to a snapshot(active state), We need
> >> to use the FORCE flag for snapshot-revert if current domain
> >> configuration is different from the target domain configuration, and
> >> this will start a new qemu instance for the target domain.
> >>
> >> In this situation, if there is existing connection to the domain, say
> >> Spice or VNC through virt-manager, Then the libvirtd would crash
> >> during snapshot revert because: Both of snapshot revert worker and
> >> new worker job 'remoteDispatchDomainOpenGraphicsFd' are waiting for
> >> mon->msg->finished in qemuMonitorSend(), We know if IO process
> >> resulted in an error with a message, Libvirtd main thread calls
> qemuMonitorIO() to wakeup the waiter.
> >> Then mon->msg will be set to NULL in qemuMonitorSend() once the
> >> worker GraphicsFD is woken up, which causes snapshot revert worker
> >> dereferences this null pointer.
> >
> > []
> >
> >> Signed-off-by: Lin Ma 
> >> ---
> >>   src/qemu/qemu_monitor.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index
> >> ea3e62dc8e..a8344e698b 100644
> >> --- a/src/qemu/qemu_monitor.c
> >> +++ b/src/qemu/qemu_monitor.c
> >> @@ -994,7 +994,7 @@ qemuMonitorSend(qemuMonitorPtr mon,
> >> "mon=%p msg=%s fd=%d",
> >> mon, mon->msg->txBuffer, mon->msg->txFD);
> >>
> >> -while (!mon->msg->finished) {
> >> +while (mon->msg && !mon->msg->finished) {
> >
> > This fixes only the symptom. The actual problem is in handling of our
> > job state when restarting the qemu process:
> >
> > Please see the following patches which aim to fix the same problem:
> >
> > https://www.redhat.com/archives/libvir-list/2019-December/msg00663.htm
> > l
> 
> In fact, I've pushed the patch yesterday:
> 
>d75f865fb9 qemu: fix concurrency crash bug in snapshot revert
> 
> Does it fix the problem you're seeing?

Yes, It does fix the problem.

Thanks,
Lin

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

Re: [libvirt] [PATCH 01/19] virsh: Add QMP command wrapping for 'qemu-monitor-command'

2019-12-13 Thread Daniel P . Berrangé
On Thu, Dec 12, 2019 at 12:16:11PM -0600, Eric Blake wrote:
> On 12/12/19 11:18 AM, Peter Krempa wrote:
> > Issuing simple QMP commands is pain as they need to be wrapped by the
> > JSON wrapper:
> > 
> >   { "execute": "COMMAND" }
> > 
> > and optionally also:
> > 
> >   { "execute": "COMMAND", "arguments":...}
> > 
> > For simple commands without arguments we can add syntax sugar to virsh
> > which allows simple usage of QMP and additionally prepares also for
> > passing through of the 'arguments' section.
> 
> I'd give an example of the new syntax in the commit message:
> 
> virsh qemu-monitor-command domain --qmp COMMAND '{ARGUMENTS...}'
> 
> as shorthand for
> 
> virsh qemu-monitor-command domain '"execute":"COMMAND",
> "arguments":{ARGUMENTS...}}'
> 
> But the sugar is indeed nice (one less layer of {} JSON).

This is still a pretty crude variant of what QEMU can do via
the 'qmp-shell' command.

I wonder if a better long term bet is to turn 'qmp-shell' into
an official QEMU tool & have it integrate with libvirt.

ie actually install qmo-shell into /usr/bin, give it a manpage
and add a '-d DOMAIN' arg as a way to tell it to send commands
to 'virsh qemu-monitor-command' instead of a UNIX socket.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



[libvirt] 回复: [PATCH] qemu: snapshot: Fix libvirtd crash in snapshot-revert

2019-12-13 Thread Lin Ma


> -邮件原件-
> 发件人: Peter Krempa 
> 发送时间: 2019年12月13日 15:56
> 收件人: Lin Ma 
> 抄送: libvir-list@redhat.com; berra...@redhat.com
> 主题: Re: [libvirt] [PATCH] qemu: snapshot: Fix libvirtd crash in 
> snapshot-revert
> 
> On Fri, Dec 13, 2019 at 15:47:36 +0800, Lin Ma wrote:
> > When reverting a running domain to a snapshot(active state), We need
> > to use the FORCE flag for snapshot-revert if current domain
> > configuration is different from the target domain configuration, and
> > this will start a new qemu instance for the target domain.
> >
> > In this situation, if there is existing connection to the domain, say
> > Spice or VNC through virt-manager, Then the libvirtd would crash
> > during snapshot revert because: Both of snapshot revert worker and new
> > worker job 'remoteDispatchDomainOpenGraphicsFd' are waiting for
> > mon->msg->finished in qemuMonitorSend(), We know if IO process
> > resulted in an error with a message, Libvirtd main thread calls
> qemuMonitorIO() to wakeup the waiter.
> > Then mon->msg will be set to NULL in qemuMonitorSend() once the worker
> > GraphicsFD is woken up, which causes snapshot revert worker
> > dereferences this null pointer.
> 
> []
> 
> > Signed-off-by: Lin Ma 
> > ---
> >  src/qemu/qemu_monitor.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index
> > ea3e62dc8e..a8344e698b 100644
> > --- a/src/qemu/qemu_monitor.c
> > +++ b/src/qemu/qemu_monitor.c
> > @@ -994,7 +994,7 @@ qemuMonitorSend(qemuMonitorPtr mon,
> >"mon=%p msg=%s fd=%d",
> >mon, mon->msg->txBuffer, mon->msg->txFD);
> >
> > -while (!mon->msg->finished) {
> > +while (mon->msg && !mon->msg->finished) {
> 
> This fixes only the symptom. The actual problem is in handling of our job 
> state
> when restarting the qemu process:
> 
> Please see the following patches which aim to fix the same problem:
> 
> https://www.redhat.com/archives/libvir-list/2019-December/msg00663.html

Indeed, It fixed the root cause, Thanks for your information.

Lin

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

Re: [libvirt] [PATCH] tools: skip libvirt-guests fast if libvirtd is not active

2019-12-13 Thread Daniel P . Berrangé
On Tue, Dec 03, 2019 at 09:56:15AM +0100, Christian Ehrhardt wrote:
> The most common operation of libvirt-guests is to manage the local
> libvirtd. But users might have disabled that and while we are
> After=libvirtd for ordering we are not Requiring it..
> OTOH adding that or any harder dependency might affect our ordering.
> 
> But if people have disabled libvirt they will do a full retry loop
> until timeout. Lets check if the local service is active at all and skip
> fast if it is not.

I don't really get why we have that retry logic at all.
If libvirtd is running, or systemd autostart is present then
virsh connect should work immediately.  If it autostarts and
no guests are present, then ther's no work todo so it'll be
fast enough.

If it fails something either it is stopped and autostart is
disabled, or it is completely broken.

Either way,  a retry loop looks pointless to me.

IOW, instead of adding a check on libvirtd, just
kill the retry loop.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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



[libvirt] [dockerfiles PATCH 1/2] Refresh Dockerfiles after recent changes

2019-12-13 Thread Andrea Bolognani
This adds the OpenVZ SDK to CentOS 7 images as well as making sure
augeas-lenses are always installed.

The corresponding libvirt-jenkins-ci commit is 2faa0d75081b.

Signed-off-by: Andrea Bolognani 
---
 buildenv-libosinfo-centos-7.zip   | Bin 570 -> 1659 bytes
 buildenv-libosinfo-centos-8.zip   | Bin 586 -> 589 bytes
 buildenv-libvirt-centos-7.zip | Bin 758 -> 1878 bytes
 buildenv-libvirt-centos-8.zip | Bin 791 -> 793 bytes
 buildenv-libvirt-debian-10-cross-aarch64.zip  | Bin 1016 -> 1021 bytes
 buildenv-libvirt-debian-10-cross-armv6l.zip   | Bin 1009 -> 1014 bytes
 buildenv-libvirt-debian-10-cross-armv7l.zip   | Bin 1013 -> 1019 bytes
 buildenv-libvirt-debian-10-cross-i686.zip | Bin 1008 -> 1016 bytes
 buildenv-libvirt-debian-10-cross-mips.zip | Bin 1003 -> 1011 bytes
 buildenv-libvirt-debian-10-cross-mips64el.zip | Bin 1017 -> 1022 bytes
 buildenv-libvirt-debian-10-cross-mipsel.zip   | Bin 1007 -> 1016 bytes
 buildenv-libvirt-debian-10-cross-ppc64le.zip  | Bin 1019 -> 1024 bytes
 buildenv-libvirt-debian-10-cross-s390x.zip| Bin 1006 -> 1011 bytes
 buildenv-libvirt-debian-10.zip| Bin 904 -> 908 bytes
 buildenv-libvirt-debian-9-cross-aarch64.zip   | Bin 1048 -> 1053 bytes
 buildenv-libvirt-debian-9-cross-armv6l.zip| Bin 1039 -> 1045 bytes
 buildenv-libvirt-debian-9-cross-armv7l.zip| Bin 1045 -> 1050 bytes
 buildenv-libvirt-debian-9-cross-mips.zip  | Bin 1039 -> 1044 bytes
 buildenv-libvirt-debian-9-cross-mips64el.zip  | Bin 1051 -> 1056 bytes
 buildenv-libvirt-debian-9-cross-mipsel.zip| Bin 1043 -> 1048 bytes
 buildenv-libvirt-debian-9-cross-ppc64le.zip   | Bin 1053 -> 1057 bytes
 buildenv-libvirt-debian-9-cross-s390x.zip | Bin 1040 -> 1045 bytes
 buildenv-libvirt-debian-9.zip | Bin 934 -> 938 bytes
 buildenv-libvirt-debian-sid-cross-aarch64.zip | Bin 1015 -> 1020 bytes
 buildenv-libvirt-debian-sid-cross-armv6l.zip  | Bin 1009 -> 1013 bytes
 buildenv-libvirt-debian-sid-cross-armv7l.zip  | Bin 1013 -> 1019 bytes
 buildenv-libvirt-debian-sid-cross-i686.zip| Bin 1008 -> 1016 bytes
 buildenv-libvirt-debian-sid-cross-mips.zip| Bin 1006 -> 1010 bytes
 ...denv-libvirt-debian-sid-cross-mips64el.zip | Bin 1017 -> 1022 bytes
 buildenv-libvirt-debian-sid-cross-mipsel.zip  | Bin 1011 -> 1016 bytes
 buildenv-libvirt-debian-sid-cross-ppc64le.zip | Bin 1018 -> 1023 bytes
 buildenv-libvirt-debian-sid-cross-s390x.zip   | Bin 1006 -> 1011 bytes
 buildenv-libvirt-debian-sid.zip   | Bin 904 -> 908 bytes
 buildenv-libvirt-ubuntu-1604.zip  | Bin 939 -> 942 bytes
 buildenv-libvirt-ubuntu-1804.zip  | Bin 941 -> 943 bytes
 35 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/buildenv-libosinfo-centos-7.zip b/buildenv-libosinfo-centos-7.zip
index ac09cf5..454ce5c 100644
--- a/buildenv-libosinfo-centos-7.zip
+++ b/buildenv-libosinfo-centos-7.zip
@@ -1,7 +1,37 @@
 FROM centos:7
 
-RUN yum update -y && \
+RUN echo -e '[openvz]\n\
+name=OpenVZ addons\n\
+baseurl=https://download.openvz.org/virtuozzo/releases/openvz-7.0.11-235/x86_64/os/\n\
+enabled=1\n\
+gpgcheck=1\n\
+skip_if_unavailable=0\n\
+metadata_expire=6h\n\
+priority=90\n\
+includepkgs=libprl*' > /etc/yum.repos.d/openvz.repo && \
+echo -e '-BEGIN PGP PUBLIC KEY BLOCK-\n\
+Version: GnuPG v2.0.22 (GNU/Linux)\n\
+\n\
+mI0EVl80nQEEAKrEeyeTCwrzS9kYedZ/sAc/GUqlb81C7pA9SaR3fyck5mVw1Ogk\n\
+YdmNBPM2kY7QDxR9F0EpSpnxSCAXZXugsQ8KzZ0DRLVeBDQyGs9IGK5hI0zzxIil\n\
+BzfvIexLiQQhLy7YlIi8Jt/uUqKkW0pIMNMGcduY97VATtczpncpkmSzABEBAAG0\n\
+SFZpcnR1b3p6byBUZWFtIChHUEcga2V5IHNpZ25hdHVyZSBmb3IgcGFja2FnZXMp\n\
+IDxzZWN1cml0eUB2aXJ0dW96em8uY29tPoi5BBMBAgAjBQJWXzSdAhsDBwsJCAcD\n\
+AgEGFQgCCQoLBBYCAwECHgECF4AACgkQygt9GUTNrSruIgP/er70Eyo73A1gfrjv\n\
+oPUkyo4rslVRZu3qqCwoMFtJc/Z/UxWgEka1buorlcGLa6eO/EZ49c0n+KGa4Kvt\n\
+EUboIq0yEu5i0FyAj92ifm+hNhoAbGfm0cZ4/fD0oGr3l8OsQo4+iHX4xAPwFe7Y\n\
+zABuB8I1ZDZ4OIp5tDfTTuF2LT24jQRWXzSdAQQAog2Aqb+Ptl68O7cQhWLjVGkj\n\
+yyigZrdeReLx3HloKJPBeQ/kA6uvMJc/IYS3uppMWXv9v+QenS6uhP1TUJ2k9FvM\n\
+t94MQZfALN7Vpf8AF+UeWu4Ru+y4BNzcFhrPhIFNFChOR2QqW6FkgE57D9I177NC\n\
+oJMyrlNe8wcGa178An8AEQEAAYifBBgBAgAJBQJWXzSdAhsMAAoJEMoLfRlEza0q\n\
+bKwD/3+OFVIEXnIv5XgdGRNX5fHggsUN1bb8gva7HANRlKdd4LD8foDM3F/yv/3V\n\
+igG14D5EjKz56SaBDNgiI4++hOzb2M8jhAsR86jxkXFrrP1U3ZNRKg6av9DPFAPS\n\
+WEiJKtQrZDJloqtyi/mmRa1VsV7RYR0VPJjhK/R8EQ7Ysshy\n\
+=fRMg\n\
+-END PGP PUBLIC KEY BLOCK-' > /etc/pki/rpm-gpg/RPM-GPG-KEY-OpenVZ && \
+rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-OpenVZ && \
 yum install -y epel-release && \
+yum update -y && \
 yum install -y \
 autoconf \
 automake \
diff --git a/buildenv-libosinfo-centos-8.zip b/buildenv-libosinfo-centos-8.zip
index 6ac848e..11621ba 100644
--- a/buildenv-libosinfo-centos-8.zip
+++ b/buildenv-libosinfo-centos-8.zip
@@ -1,9 +1,9 @@
 FROM centos:8
 
-RUN dnf update -y && \
-dnf install 'dnf-command(config-manager)' -y && \
+RUN dnf install 

[libvirt] [dockerfiles PATCH 0/2] Refresh and add openSUSE Leap 15.1

2019-12-13 Thread Andrea Bolognani
Pushed under the Dockerfile refresh rule. Text diffs are provided.

Andrea Bolognani (2):
  Refresh Dockerfiles after recent changes
  Add openSUSE Leap 15.1 Dockerfile for libvirt

 buildenv-libosinfo-centos-7.zip   | Bin 570 -> 1659 bytes
 buildenv-libosinfo-centos-8.zip   | Bin 586 -> 589 bytes
 buildenv-libvirt-centos-7.zip | Bin 758 -> 1878 bytes
 buildenv-libvirt-centos-8.zip | Bin 791 -> 793 bytes
 buildenv-libvirt-debian-10-cross-aarch64.zip  | Bin 1016 -> 1021 bytes
 buildenv-libvirt-debian-10-cross-armv6l.zip   | Bin 1009 -> 1014 bytes
 buildenv-libvirt-debian-10-cross-armv7l.zip   | Bin 1013 -> 1019 bytes
 buildenv-libvirt-debian-10-cross-i686.zip | Bin 1008 -> 1016 bytes
 buildenv-libvirt-debian-10-cross-mips.zip | Bin 1003 -> 1011 bytes
 buildenv-libvirt-debian-10-cross-mips64el.zip | Bin 1017 -> 1022 bytes
 buildenv-libvirt-debian-10-cross-mipsel.zip   | Bin 1007 -> 1016 bytes
 buildenv-libvirt-debian-10-cross-ppc64le.zip  | Bin 1019 -> 1024 bytes
 buildenv-libvirt-debian-10-cross-s390x.zip| Bin 1006 -> 1011 bytes
 buildenv-libvirt-debian-10.zip| Bin 904 -> 908 bytes
 buildenv-libvirt-debian-9-cross-aarch64.zip   | Bin 1048 -> 1053 bytes
 buildenv-libvirt-debian-9-cross-armv6l.zip| Bin 1039 -> 1045 bytes
 buildenv-libvirt-debian-9-cross-armv7l.zip| Bin 1045 -> 1050 bytes
 buildenv-libvirt-debian-9-cross-mips.zip  | Bin 1039 -> 1044 bytes
 buildenv-libvirt-debian-9-cross-mips64el.zip  | Bin 1051 -> 1056 bytes
 buildenv-libvirt-debian-9-cross-mipsel.zip| Bin 1043 -> 1048 bytes
 buildenv-libvirt-debian-9-cross-ppc64le.zip   | Bin 1053 -> 1057 bytes
 buildenv-libvirt-debian-9-cross-s390x.zip | Bin 1040 -> 1045 bytes
 buildenv-libvirt-debian-9.zip | Bin 934 -> 938 bytes
 buildenv-libvirt-debian-sid-cross-aarch64.zip | Bin 1015 -> 1020 bytes
 buildenv-libvirt-debian-sid-cross-armv6l.zip  | Bin 1009 -> 1013 bytes
 buildenv-libvirt-debian-sid-cross-armv7l.zip  | Bin 1013 -> 1019 bytes
 buildenv-libvirt-debian-sid-cross-i686.zip| Bin 1008 -> 1016 bytes
 buildenv-libvirt-debian-sid-cross-mips.zip| Bin 1006 -> 1010 bytes
 ...denv-libvirt-debian-sid-cross-mips64el.zip | Bin 1017 -> 1022 bytes
 buildenv-libvirt-debian-sid-cross-mipsel.zip  | Bin 1011 -> 1016 bytes
 buildenv-libvirt-debian-sid-cross-ppc64le.zip | Bin 1018 -> 1023 bytes
 buildenv-libvirt-debian-sid-cross-s390x.zip   | Bin 1006 -> 1011 bytes
 buildenv-libvirt-debian-sid.zip   | Bin 904 -> 908 bytes
 buildenv-libvirt-opensuse-151.zip | Bin 0 -> 761 bytes
 buildenv-libvirt-ubuntu-1604.zip  | Bin 939 -> 942 bytes
 buildenv-libvirt-ubuntu-1804.zip  | Bin 941 -> 943 bytes
 36 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 buildenv-libvirt-opensuse-151.zip

-- 
2.23.0

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



[libvirt] [PATCH] docs: remove link to virsh cmd ref & app dev guide

2019-12-13 Thread Daniel P . Berrangé
Both the application developer guide and virsh command
reference are unmaintained for best part of 8 years, and
so horrifically out of date. This does not give a good
impression to people reading the docs. Now that we are
publishing the man pages online, those are a better
doc to read for virsh.  We can also highlight the API
reference instead of the app dev guide.

The virsh command reference & app dev guide will
still exist on the web root, but will not be linked
to.

Signed-off-by: Daniel P. Berrangé 
---
 docs/docs.html.in | 48 +--
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/docs/docs.html.in b/docs/docs.html.in
index b592f7d51f..004f099a9f 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -54,11 +54,27 @@
 
   Application development
   
-Development Guide
-A guide and reference for developing with libvirt
-
-Virsh Commands
-Command reference for virsh
+API reference
+Reference manual for the C public API, split in
+  common,
+  domain,
+  domain 
checkpoint,
+  domain 
snapshot,
+  error,
+  event,
+  host,
+  interface,
+  network,
+  node device,
+  network filter,
+  secret,
+  storage,
+  stream
+  and
+  admin,
+  QEMU,
+  LXC libs
+
 
 Language bindings and API modules
 Bindings of the libvirt API for
@@ -97,28 +113,6 @@
 CGroups
 Control groups integration
 
-API reference
-Reference manual for the C public API, split in
-  common,
-  domain,
-  domain 
checkpoint,
-  domain 
snapshot,
-  error,
-  event,
-  host,
-  interface,
-  network,
-  node device,
-  network filter,
-  secret,
-  storage,
-  stream
-  and
-  admin,
-  QEMU,
-  LXC libs
-
-
 Drivers
 Hypervisor specific driver information
 
-- 
2.21.0

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

[libvirt] [dockerfiles PATCH 2/2] Add openSUSE Leap 15.1 Dockerfile for libvirt

2019-12-13 Thread Andrea Bolognani
libosinfo and related projects are not supported yet, so the
corresponding Dockerfile will have to be added at a later time.

The corresponding libvirt-jenkins-ci commit is 5a4c5191fd68.

Signed-off-by: Andrea Bolognani 
---
 buildenv-libvirt-opensuse-151.zip | Bin 0 -> 761 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 buildenv-libvirt-opensuse-151.zip

diff --git a/buildenv-libvirt-opensuse-151.zip 
b/buildenv-libvirt-opensuse-151.zip
new file mode 100644
index 000..701149f
--- /dev/null
+++ b/buildenv-libvirt-opensuse-151.zip
@@ -0,0 +1,96 @@
+FROM opensuse/leap:15.1
+
+RUN zypper update -y && \
+zypper install -y \
+   audit-devel \
+   augeas \
+   augeas-lenses \
+   autoconf \
+   automake \
+   avahi-devel \
+   bash \
+   bash-completion \
+   ca-certificates \
+   ccache \
+   chrony \
+   cppi \
+   cyrus-sasl-devel \
+   dbus-1-devel \
+   device-mapper-devel \
+   dnsmasq \
+   dwarves \
+   ebtables \
+   fuse-devel \
+   gcc \
+   gdb \
+   gettext \
+   gettext-devel \
+   git \
+   glib2-devel \
+   glibc-devel \
+   glibc-locale \
+   glusterfs-devel \
+   iproute2 \
+   kmod \
+   libacl-devel \
+   libapparmor-devel \
+   libattr-devel \
+   libblkid-devel \
+   libcap-ng-devel \
+   libcurl-devel \
+   libgnutls-devel \
+   libiscsi-devel \
+   libnl3-devel \
+   libnuma-devel \
+   libpcap-devel \
+   libpciaccess-devel \
+   librbd-devel \
+   libselinux-devel \
+   libssh-devel \
+   libssh2-devel \
+   libtirpc-devel \
+   libtool \
+   libudev-devel \
+   libwsman-devel \
+   libxml2 \
+   libxml2-devel \
+   libxslt \
+   libyajl-devel \
+   lsof \
+   lvm2 \
+   make \
+   meson \
+   ncurses-devel \
+   net-tools \
+   nfs-utils \
+   ninja \
+   numad \
+   open-iscsi \
+   parted \
+   parted-devel \
+   patch \
+   perl \
+   pkgconfig \
+   polkit \
+   python3 \
+   python3-docutils \
+   python3-flake8 \
+   python3-setuptools \
+   qemu-tools \
+   radvd \
+   readline-devel \
+   rpcgen \
+   rpm-build \
+   sanlock-devel \
+   screen \
+   scrub \
+   strace \
+   sudo \
+   systemtap-sdt-devel \
+   vim \
+   wireshark-devel \
+   xen-devel \
+   xfsprogs-devel && \
+zypper clean --all
+
+ENV LANG "en_US.UTF-8"

-- 
2.23.0

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



Re: [libvirt] [PATCH] qemu: snapshot: Fix libvirtd crash in snapshot-revert

2019-12-13 Thread Michal Privoznik

On 12/13/19 8:55 AM, Peter Krempa wrote:

On Fri, Dec 13, 2019 at 15:47:36 +0800, Lin Ma wrote:

When reverting a running domain to a snapshot(active state), We need to
use the FORCE flag for snapshot-revert if current domain configuration
is different from the target domain configuration, and this will start a
new qemu instance for the target domain.

In this situation, if there is existing connection to the domain, say
Spice or VNC through virt-manager, Then the libvirtd would crash during
snapshot revert because: Both of snapshot revert worker and new worker
job 'remoteDispatchDomainOpenGraphicsFd' are waiting for mon->msg->finished
in qemuMonitorSend(), We know if IO process resulted in an error with a
message, Libvirtd main thread calls qemuMonitorIO() to wakeup the waiter.
Then mon->msg will be set to NULL in qemuMonitorSend() once the worker
GraphicsFD is woken up, which causes snapshot revert worker dereferences
this null pointer.


[]


Signed-off-by: Lin Ma 
---
  src/qemu/qemu_monitor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index ea3e62dc8e..a8344e698b 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -994,7 +994,7 @@ qemuMonitorSend(qemuMonitorPtr mon,
"mon=%p msg=%s fd=%d",
mon, mon->msg->txBuffer, mon->msg->txFD);
  
-while (!mon->msg->finished) {

+while (mon->msg && !mon->msg->finished) {


This fixes only the symptom. The actual problem is in handling of our
job state when restarting the qemu process:

Please see the following patches which aim to fix the same problem:

https://www.redhat.com/archives/libvir-list/2019-December/msg00663.html


In fact, I've pushed the patch yesterday:

  d75f865fb9 qemu: fix concurrency crash bug in snapshot revert

Does it fix the problem you're seeing?

Michal

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



Re: [libvirt] [PATCH 11/19] tests: qemublock: Add test case for detecting bitmaps as we create snapshots

2019-12-13 Thread Peter Krempa
On Thu, Dec 12, 2019 at 13:38:29 -0600, Eric Blake wrote:
> On 12/12/19 11:18 AM, Peter Krempa wrote:
> > Add test data gathered from a run of qemu after creating bitmaps and
> > snapshots together in various combinations.
> > 

I'll also add how to get to the bitmap topology.

> > Signed-off-by: Peter Krempa 
> > ---
> >   tests/qemublocktest.c |   1 +
> >   tests/qemublocktestdata/bitmap/snapshots.json | 836 ++
> 
> Huge!

We really want 'query-named-block-nodes' not deal with the backing file.
I'll investigate whether there's a simple-enough way to make qemu stop
producing the nested input when we provide some new flag.

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



[libvirt] [libvirt-tck PATCH] Add cases for nvram

2019-12-13 Thread Dan Zheng
This is to add the tests for below flags:
- Sys::Virt::Domain::UNDEFINE_KEEP_NVRAM
- Sys::Virt::Domain::UNDEFINE_NVRAM

Signed-off-by: Dan Zheng 
---
 scripts/domain/401-ovmf-nvram.t | 143 
 1 file changed, 143 insertions(+)
 create mode 100644 scripts/domain/401-ovmf-nvram.t

diff --git a/scripts/domain/401-ovmf-nvram.t b/scripts/domain/401-ovmf-nvram.t
new file mode 100644
index 000..5310dd0
--- /dev/null
+++ b/scripts/domain/401-ovmf-nvram.t
@@ -0,0 +1,143 @@
+# -*- perl -*-
+#
+# Copyright (C) 2009 Red Hat, Inc.
+# Copyright (C) 2018 Dan Zheng (dzh...@redhat.com)
+#
+# This program is free software; You can redistribute it and/or modify
+# it under the GNU General Public License as published by the Free
+# Software Foundation; either version 2, or (at your option) any
+# later version
+#
+# The file "LICENSE" distributed along with this file provides full
+# details of the terms and conditions
+#
+
+=pod
+
+=head1 NAME
+
+domain/401-ovmf-nvram.t - Test OVMF related functions and flags
+
+=head1 DESCRIPTION
+
+The test cases validates OVMF related APIs and flags
+
+Sys::Virt::Domain::UNDEFINE_KEEP_NVRAM
+Sys::Virt::Domain::UNDEFINE_NVRAM
+
+=cut
+
+use strict;
+use warnings;
+
+use Test::More tests => 8;
+
+use Sys::Virt::TCK;
+use File::stat;
+use File::Copy;
+
+
+my $tck = Sys::Virt::TCK->new();
+my $conn = eval { $tck->setup(); };
+BAIL_OUT "failed to setup test harness: $@" if $@;
+END { $tck->cleanup if $tck; }
+
+
+sub setup_nvram {
+
+my $loader_path = shift;
+my $nvram_template = shift;
+my $nvram_path = shift;
+
+# Install OVMF and check the two files should exist
+#  - /usr/share/OVMF/OVMF_CODE.secboot.fd
+#  - /usr/share/OVMF/OVMF_VARS.fd
+
+my $ret = `yum install -y OVMF`;
+diag "yum install OVMF: $ret";
+my $st = stat($loader_path);
+ok($st, "path $loader_path exists after OVMF is installed");
+$st = stat($nvram_template);
+ok($st, "path $nvram_template exists after OVMF is installed");
+
+# Ensure the sample nvram file exists
+copy($nvram_template, $nvram_path) or die "Copy failed: $!";
+
+# Use 'q35' as machine type and add below lines to guest xml
+# /usr/share/OVMF/OVMF_CODE.secboot.fd
+# /var/lib/libvirt/qemu/nvram/test_VARS.fd
+
+my $xml = $tck->generic_domain(name => "tck")->as_xml;
+my $xp = XML::XPath->new($xml);
+diag $xp->getNodeText("/domain/os/type/\@machine");
+
+diag "Changing guest machine type to q35";
+$xp->setNodeText("/domain/os/type/\@machine", "q35");
+
+my $loader_node = XML::XPath::Node::Element->new('loader');
+my $loader_text   = XML::XPath::Node::Text->new($loader_path);
+my $attr_ro = XML::XPath::Node::Attribute->new('readonly');
+my $attr_secure = XML::XPath::Node::Attribute->new('secure');
+my $attr_type = XML::XPath::Node::Attribute->new('type');
+
+$attr_ro -> setNodeValue('yes');
+$attr_secure -> setNodeValue('yes');
+$attr_type   -> setNodeValue('pflash');
+
+$loader_node->appendChild($loader_text);
+$loader_node->appendAttribute($attr_ro);
+$loader_node->appendAttribute($attr_secure);
+$loader_node->appendAttribute($attr_type);
+
+my $nvram_node= XML::XPath::Node::Element->new('nvram');
+my $nvram_text= XML::XPath::Node::Text->new($nvram_path);
+my $attr_template = XML::XPath::Node::Attribute->new('template');
+
+$attr_template -> setNodeValue($nvram_template);
+
+$nvram_node->appendChild($nvram_text);
+$nvram_node->appendAttribute($attr_template);
+
+my $smm_node   = XML::XPath::Node::Element->new('smm');
+my $attr_state = XML::XPath::Node::Attribute->new('state');
+$attr_state -> setNodeValue("on");
+$smm_node -> appendAttribute($attr_state);
+
+my ($root) = $xp->findnodes('/domain/os');
+$root->appendChild($loader_node);
+$root->appendChild($nvram_node);
+($root) = $xp->findnodes('/domain/features');
+$root->appendChild($smm_node);
+
+$xml = $xp->findnodes_as_string('/');
+diag $xml;
+return $xml;
+}
+
+diag "Defining an inactive domain config with nvram";
+my $loader_file_path = '/usr/share/OVMF/OVMF_CODE.secboot.fd';
+my $nvram_file_template = '/usr/share/OVMF/OVMF_VARS.fd';
+my $nvram_file_path = '/var/lib/libvirt/qemu/nvram/test_VARS.fd';
+
+my $xml = setup_nvram($loader_file_path, $nvram_file_template, 
$nvram_file_path);
+my $dom;
+
+diag "Test Sys::Virt::Domain::UNDEFINE_KEEP_NVRAM";
+ok_domain(sub { $dom = $conn->define_domain($xml) }, "defined domain with 
nvram configure");
+diag "Checking nvram file already exists";
+my $st = stat($nvram_file_path);
+ok($st, "File '$nvram_file_path' exists as expected");
+$dom->undefine(Sys::Virt::Domain::UNDEFINE_KEEP_NVRAM);
+diag "Checking nvram file still exists";
+$st = stat($nvram_file_path);
+ok($st, "File '$nvram_file_path' still exists as expected");
+
+diag "Test Sys::Virt::Domain::UNDEFINE_NVRAM";
+ok_domain(sub { $dom = $conn->define_domain($xml) }, "defined domain with 
nvram configure");
+$dom->undefine(Sys::Virt::Domain::UNDEFINE_NVRAM);
+diag "Checking nvram file removed";
+$st = stat($nvram_file_path);
+ok(!$st, "File 

Re: [libvirt] [PATCH 03/19] qemu: monitor: Extract data about dirty-bimaps in qemuMonitorBlockGetNamedNodeData

2019-12-13 Thread Peter Krempa
On Thu, Dec 12, 2019 at 12:30:54 -0600, Eric Blake wrote:
> On 12/12/19 11:18 AM, Peter Krempa wrote:
> > We will need to inspect the presence and attributes for dirty bitmaps.
> > Extract them when processing reply of query-named-block-nodes.
> > 
> > Signed-off-by: Peter Krempa 
> > ---
> >   src/qemu/qemu_monitor.h  | 15 
> >   src/qemu/qemu_monitor_json.c | 74 
> >   2 files changed, 89 insertions(+)
> > 
> 
> > +static void
> > +qemuMonitorJSONBlockGetNamedNodeDataBitmaps(virJSONValuePtr bitmaps,
> > +qemuBlockNamedNodeDataPtr data)
> > +{
> > +size_t nbitmaps = virJSONValueArraySize(bitmaps);
> > +size_t i;
> > +
> > +data->bitmaps = g_new0(qemuBlockNamedNodeDataBitmapPtr, nbitmaps);
> > +
> > +for (i = 0; i < nbitmaps; i++) {
> > +virJSONValuePtr bitmap = virJSONValueArrayGet(bitmaps, i);
> > +qemuBlockNamedNodeDataBitmapPtr tmp;
> > +
> > +if (!bitmap)
> > +continue;
> 
> Can bitmap ever be NULL?  (We could assert that it is not, given our correct
> usage of the API - except that we aren't using asserts).  But doesn't hurt
> to leave the check in.

AFAIK the JSON parser guarantees that it's not NULL, but given that the
return value of virJSONValueArrayGet is checked in many places I think
it would make static analyzers think it might return NULL and start
moaning.

> 
> Reviewed-by: Eric Blake 
> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org
> 
> --
> 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