Re: [libvirt] [PATCH] virsh.pod: Mention iscsi-direct is supported in find-storage-pool-sources
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> -邮件原件-
> 发件人: 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'
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
> -邮件原件-
> 发件人: 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
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
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
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
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
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
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
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
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
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
