Re: [libvirt] [PATCH v6.1 2/9] libxl: pass driver config to libxlMakeDomBuildInfo

[Marek Marczykowski-Górecki]

On Wed, Mar 28, 2018 at 01:42:47PM -0600, Jim Fehlig wrote:
> On 03/27/2018 05:55 PM, Marek Marczykowski-Górecki wrote:
> > diff --git a/tests/virmocklibxl.c b/tests/virmocklibxl.c
> > index 747f9f8..28281b6 100644
> > --- a/tests/virmocklibxl.c
> > +++ b/tests/virmocklibxl.c
> > @@ -27,6 +27,7 @@
> >   # include 
> >   # include 
> >   # include 
> > +# include 
> >   # include 
> >   # include 
> > @@ -48,6 +49,24 @@ VIR_MOCK_IMPL_RET_ARGS(xc_interface_open,
> >   }
> > +VIR_MOCK_IMPL_RET_ARGS(libxl_get_version_info,
> > +   const libxl_version_info*,
> > +   libxl_ctx *, ctx)
> > +{
> > +static libxl_version_info info;
> > +
> > +memset(, 0, sizeof(info));
> > +
> > +return 
> > +/* silence gcc warning */
> > +return real_libxl_get_version_info(ctx);
> > +}
> > +
> > +VIR_MOCK_STUB_RET_ARGS(libxl_get_free_memory,
> > +   int, 0,
> > +   libxl_ctx *, ctx,
> > +   uint32_t *, memkb);
> > +
> 
> This doesn't compile with Xen >= 4.8
> 
> In file included from virmocklibxl.c:26:0:
> virmocklibxl.c:66:24: error: conflicting types for 'libxl_get_free_memory'
>  VIR_MOCK_STUB_RET_ARGS(libxl_get_free_memory,
> ^
> virmock.h:182:13: note: in definition of macro 'VIR_MOCK_STUB_RET_ARGS'
>  rettype name(VIR_MOCK_ARGTYPENAMES_UNUSED(__VA_ARGS__)) \
>  ^~~~
> In file included from virmocklibxl.c:29:0:
> /usr/include/libxl.h:1570:5: note: previous declaration of
> 'libxl_get_free_memory' was here
>  int libxl_get_free_memory(libxl_ctx *ctx, uint64_t *memkb);
>  ^
> 
> Using the uint32_t variant works in the libxl driver since we have
> -DLIBXL_API_VERSION=0x040400 in LIBXL_CFLAGS. I worked around the
> compilation failure with LIBXL_HAVE_MEMKB_64BITS, 

I can't reproduce this problem, either with 4.8 or 4.10. Even more, if I
add alternative mock with uint64_t, under #if LIBXL_HAVE_MEMKB_64BITS, I
get compile failure, because of conflicting types (with
libxl_get_free_memory_0x040700)...

Can you confirm it's really a problem, not some mismatching header
versions on your side?

> but then
> libxlxml2domconfigtest crashed.

I've got test failure, apparently because something have changed with
VGA model in json format. I'll remove it from the test, as it is
unrelated to CPUID.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[libvirt] [qemu RFC] qapi: add "firmware.json"

[Laszlo Ersek]

Add a schema that describes the properties of virtual machine firmware.

Each firmware executable installed on a host system should come with a
JSON file that conforms to this schema, and informs the management
applications about the firmware's properties.

In addition, a configuration directory with symlinks to the JSON files
should exist, with the symlinks carefully named to reflect a priority
order. Management applications can then search this directory in priority
order for the first firmware executable that satisfies their search
criteria. The found JSON file provides the management layer with domain
configuration bits that are required to run the firmware binary.

Cc: "Daniel P. Berrange" 
Cc: Alexander Graf 
Cc: Ard Biesheuvel 
Cc: David Gibson 
Cc: Eric Blake 
Cc: Gary Ching-Pang Lin 
Cc: Gerd Hoffmann 
Cc: Kashyap Chamarthy 
Cc: Markus Armbruster 
Cc: Michael Roth 
Cc: Michal Privoznik 
Cc: Peter Krempa 
Cc: Peter Maydell 
Cc: Thomas Huth 
Signed-off-by: Laszlo Ersek 
---

Notes:
Folks on the CC list, please try to see if the suggested schema is
flexible enough to describe the virtual firmware(s) that you are
familiar with. Thanks!

 Makefile  |   9 ++
 Makefile.objs |   4 +
 qapi/firmware.json| 343 ++
 qapi/qapi-schema.json |   1 +
 qmp.c |   5 +
 .gitignore|   4 +
 6 files changed, 366 insertions(+)
 create mode 100644 qapi/firmware.json

diff --git a/Makefile b/Makefile
index 727ef118f3d9..e088e3c1b39f 100644
--- a/Makefile
+++ b/Makefile
@@ -97,6 +97,7 @@ GENERATED_FILES += qapi/qapi-types-block.h 
qapi/qapi-types-block.c
 GENERATED_FILES += qapi/qapi-types-char.h qapi/qapi-types-char.c
 GENERATED_FILES += qapi/qapi-types-common.h qapi/qapi-types-common.c
 GENERATED_FILES += qapi/qapi-types-crypto.h qapi/qapi-types-crypto.c
+GENERATED_FILES += qapi/qapi-types-firmware.h qapi/qapi-types-firmware.c
 GENERATED_FILES += qapi/qapi-types-introspect.h qapi/qapi-types-introspect.c
 GENERATED_FILES += qapi/qapi-types-migration.h qapi/qapi-types-migration.c
 GENERATED_FILES += qapi/qapi-types-misc.h qapi/qapi-types-misc.c
@@ -115,6 +116,7 @@ GENERATED_FILES += qapi/qapi-visit-block.h 
qapi/qapi-visit-block.c
 GENERATED_FILES += qapi/qapi-visit-char.h qapi/qapi-visit-char.c
 GENERATED_FILES += qapi/qapi-visit-common.h qapi/qapi-visit-common.c
 GENERATED_FILES += qapi/qapi-visit-crypto.h qapi/qapi-visit-crypto.c
+GENERATED_FILES += qapi/qapi-visit-firmware.h qapi/qapi-visit-firmware.c
 GENERATED_FILES += qapi/qapi-visit-introspect.h qapi/qapi-visit-introspect.c
 GENERATED_FILES += qapi/qapi-visit-migration.h qapi/qapi-visit-migration.c
 GENERATED_FILES += qapi/qapi-visit-misc.h qapi/qapi-visit-misc.c
@@ -132,6 +134,7 @@ GENERATED_FILES += qapi/qapi-commands-block.h 
qapi/qapi-commands-block.c
 GENERATED_FILES += qapi/qapi-commands-char.h qapi/qapi-commands-char.c
 GENERATED_FILES += qapi/qapi-commands-common.h qapi/qapi-commands-common.c
 GENERATED_FILES += qapi/qapi-commands-crypto.h qapi/qapi-commands-crypto.c
+GENERATED_FILES += qapi/qapi-commands-firmware.h qapi/qapi-commands-firmware.c
 GENERATED_FILES += qapi/qapi-commands-introspect.h 
qapi/qapi-commands-introspect.c
 GENERATED_FILES += qapi/qapi-commands-migration.h 
qapi/qapi-commands-migration.c
 GENERATED_FILES += qapi/qapi-commands-misc.h qapi/qapi-commands-misc.c
@@ -149,6 +152,7 @@ GENERATED_FILES += qapi/qapi-events-block.h 
qapi/qapi-events-block.c
 GENERATED_FILES += qapi/qapi-events-char.h qapi/qapi-events-char.c
 GENERATED_FILES += qapi/qapi-events-common.h qapi/qapi-events-common.c
 GENERATED_FILES += qapi/qapi-events-crypto.h qapi/qapi-events-crypto.c
+GENERATED_FILES += qapi/qapi-events-firmware.h qapi/qapi-events-firmware.c
 GENERATED_FILES += qapi/qapi-events-introspect.h qapi/qapi-events-introspect.c
 GENERATED_FILES += qapi/qapi-events-migration.h qapi/qapi-events-migration.c
 GENERATED_FILES += qapi/qapi-events-misc.h qapi/qapi-events-misc.c
@@ -581,6 +585,7 @@ qapi-modules = $(SRC_PATH)/qapi/qapi-schema.json 
$(SRC_PATH)/qapi/common.json \
$(SRC_PATH)/qapi/block.json $(SRC_PATH)/qapi/block-core.json \
$(SRC_PATH)/qapi/char.json \
$(SRC_PATH)/qapi/crypto.json \
+   $(SRC_PATH)/qapi/firmware.json \
$(SRC_PATH)/qapi/introspect.json \
$(SRC_PATH)/qapi/migration.json \
$(SRC_PATH)/qapi/misc.json \
@@ -600,6 +605,7 @@ qapi/qapi-types-block.c qapi/qapi-types-block.h \
 qapi/qapi-types-char.c qapi/qapi-types-char.h \
 qapi/qapi-types-common.c qapi/qapi-types-common.h \
 qapi/qapi-types-crypto.c 

[libvirt] Permissions and ownership on /dev/kvm keep reverting after starting a vm

[Tom]

Hey guys,

/dev/kvm permissions and ownership keeps reverting after starting a vm.

The ownership and permissions keep going back to 

crw-rw—— root root 

After starting a vm.  I have to revert the perms and ownership to:

crw-crw-crw root kvm 

To start any vm but it goes back to the first set of permissions as soon as I 
start another vm.  Any hints what I could check?

Cheers,
Tom

Sent from my iPhone

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

Re: [libvirt] [PATCH v2] docs: add page describing goals for host platform version support

[Jim Fehlig]

On 04/05/2018 04:05 AM, Daniel P. Berrangé wrote:

Described how we decide which host platforms to support for libvirt,
which in turn makes it easier to decide when a platform / software
version can be dropped.

Signed-off-by: Daniel P. Berrangé 
---
  docs/index.html.in |   2 +-
  docs/platforms.html.in | 105 +
  2 files changed, 106 insertions(+), 1 deletion(-)
  create mode 100644 docs/platforms.html.in

diff --git a/docs/index.html.in b/docs/index.html.in
index 1b3a7a3db6..4783c39e3c 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -28,7 +28,7 @@
  The libvirt project:


-is a toolkit to manage virtualization hosts
+is a toolkit to manage virtualization 
platforms
  is accessible from C, Python, Perl, Java and more
  is licensed under open source licenses
  supports KVM,
diff --git a/docs/platforms.html.in b/docs/platforms.html.in
new file mode 100644
index 00..776e930e78
--- /dev/null
+++ b/docs/platforms.html.in
@@ -0,0 +1,105 @@
+
+
+http://www.w3.org/1999/xhtml;>
+  
+Supported host platforms
+
+
+
+Build targets
+
+
+  Libvirt drivers aim to support building and executing on multiple
+  host OS platforms. This document outlines which platforms are the
+  major build targets. These platforms are used as the basis for deciding
+  upon the minimum required versions of 3rd party software libvirt depends
+  on. If a platform is not listed here, it does not imply that libvirt
+  won't work. If an unlisted platform has comparable software versions
+  to a listed platform, there is every expectation that it will work.
+  Bug reports are welcome for problems encountered on unlisted platforms
+  unless they are clearly older vintage that what is described here.
+
+
+
+  Note that when considering software versions shipped in distros as
+  support targets, libvirt considers only the version number, and assumes
+  the features in that distro match the upstream release with the same
+  version. IOW, if a distro backports extra features to the software in
+  their distro, libvirt upstream code will not add explicit support for
+  those backports, unless the feature is auto-detectable in a manner that
+  works for the upstream releases too.
+
+
+
+  The Repology site is a useful resource to identify currently shipped
+  versions of software in various operating systems, though it does not
+  cover all distros listed below.
+
+
+
+  https://repology.org/metapackage/libvirt/versions;>libvirt
+  https://repology.org/metapackage/qemu/versions;>qemu
+
+
+
+Linux OS
+
+
+  For distributions with frequent, short-lifetime releases, the project
+  will aim to support all versions that are not end of life by their
+  respective vendors. For the purposes of identifying supported software
+  versions, the project will look at Fedora, Ubuntu  OpenSUSE distros.


openSUSE

Regards,
Jim


+  Other short-lifetime distros will be assumed to ship similar software
+  versions.
+
+
+
+  For distributions with long-lifetime releases, the project will aim to
+  support the most recent major version at all times. Support for the
+  previous major version will be dropped 2 years after the new major
+  version is released. For the purposes of identifying supported software
+  versions, the project will look at RHEL, Debian, Ubuntu LTS  SLES
+  distros. Other long-lifetime distros will be assumed to ship similar
+  software versions.
+
+
+Windows
+
+
+  The project supports building with current versions of the MinGW
+  toolchain, hosted on Linux.
+
+
+macOS
+
+
+  The project supports building with the current version of macOS,
+  with the current homebrew package set available.
+
+
+FreeBSD
+
+
+  The project aims to support the most recent major version
+  at all times. Support for the previous major version will
+  be dropped 2 years after the new major version is released.
+
+
+Virtualization platforms
+
+
+  For hypervisor drivers which execute
+  locally (QEMU, LXC, VZ, libxl, etc), the set of supported operating
+  system platforms listed above will inform choices as to the minimum
+  required versions of 3rd party libraries and hypervisor management
+  APIs.
+
+
+  If a hypervisor is not commonly shipped directly by any distro
+  listed above, (VMware ESX, HyperV, VZ), the project aims to
+  support versions up to 5 years, or until the vendor discontinues
+  support, whichever comes first.
+
+
+  
+



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

Re: [libvirt] [PATCH 0/7] Remove the legacy xen driver

[Jim Fehlig]

On 04/03/2018 08:26 AM, Daniel P. Berrangé wrote:

On Wed, Mar 28, 2018 at 08:58:25PM -0600, Jim Fehlig wrote:

Long overdue first cut at remove the old xen driver. The first 3 patches
move existing tests to WITH_LIBXL since we'll want to continue supporting
conversion of the various xen config formats. The remain patches remove
the cruft.

Jim Fehlig (7):
   tests: move xml2sexpr tests to WITH_LIBXL
   tests: move sexpr2xml tests to WITH_LIBXL
   tests: move xmconfig tests to WITH_LIBXL
   Remove xencaps tests and data files
   Remove the xend driver
   docs: remove mention of legacy Xen driver
   spec: remove legacy xen driver

  configure.ac   |7 +-
  docs/architecture.html.in  |   28 +-
  docs/bugs.html.in  |3 +-
  docs/uri.html.in   |   74 -
  docs/windows.html.in   |2 +-


This needs an update to docs/drvxen.html.in most importantly. That
actually claims libxl driver is used from Xen 4.2 onwards if available.


Heh, the most obvious page needing updated. I thought I had taken care of it, 
but it was a late night when I was trying to get these pushed out. V2 sent.


Regards,
Jim

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

[libvirt] [PATCH V2 1/8] tests: move xml2sexpr tests to WITH_LIBXL

[Jim Fehlig]

In preparation of removing the legacy Xen driver, move the
xml2sexpr tests from WITH_XEN to WITH_LIBXL. Even though the
legacy driver will be removed, we'll want to maintain the ability
to convert sexpr <-> XML.

There is some test file fallout due to differences in handling
of default values between xend and libxl.

Signed-off-by: Jim Fehlig 
---
 tests/Makefile.am  | 18 +-
 tests/xml2sexprdata/xml2sexpr-escape.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr  |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-force-nohpet.sexpr|  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-kernel.sexpr  |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr   |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr|  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr|  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-parallel-tcp.sexpr|  2 +-
 .../xml2sexpr-fv-serial-dev-2-ports.sexpr  |  2 +-
 .../xml2sexpr-fv-serial-dev-2nd-port.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-file.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-null.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-pipe.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-pty.sexpr  |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-stdio.sexpr|  2 +-
 .../xml2sexprdata/xml2sexpr-fv-serial-tcp-telnet.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-tcp.sexpr  |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-udp.sexpr  |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-serial-unix.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-sound.sexpr   |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-usbmouse.sexpr|  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-utc.sexpr |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-v2.sexpr  |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv-vncunused.sexpr   |  2 +-
 tests/xml2sexprdata/xml2sexpr-fv.sexpr |  2 +-
 tests/xml2sexprtest.c  |  7 +++
 27 files changed, 37 insertions(+), 38 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index f2f5caed4..8e48acc69 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -273,12 +273,12 @@ ssh_SOURCES = ssh.c
 ssh_LDADD = $(COVERAGE_LDFLAGS)
 
 if WITH_XEN
-test_programs += xml2sexprtest sexpr2xmltest \
+test_programs += sexpr2xmltest \
xmconfigtest xencapstest
 endif WITH_XEN
 
 if WITH_LIBXL
-test_programs += xlconfigtest libxlxml2domconfigtest
+test_programs += xlconfigtest xml2sexprtest libxlxml2domconfigtest
 test_libraries += virmocklibxl.la
 endif WITH_LIBXL
 
@@ -502,11 +502,6 @@ if WITH_XEN
 xen_LDADDS = ../src/libvirt_driver_xen_impl.la
 xen_LDADDS += $(LDADDS)
 
-xml2sexprtest_SOURCES = \
-   xml2sexprtest.c testutilsxen.c testutilsxen.h \
-   testutils.c testutils.h
-xml2sexprtest_LDADD = $(xen_LDADDS)
-
 sexpr2xmltest_SOURCES = \
sexpr2xmltest.c testutilsxen.c testutilsxen.h \
testutils.c testutils.h
@@ -522,7 +517,7 @@ xencapstest_SOURCES = \
 xencapstest_LDADD = $(xen_LDADDS)
 
 else ! WITH_XEN
-EXTRA_DIST += xml2sexprtest.c sexpr2xmltest.c xmconfigtest.c \
+EXTRA_DIST += sexpr2xmltest.c xmconfigtest.c \
xencapstest.c \
testutilsxen.c testutilsxen.h
 endif ! WITH_XEN
@@ -539,6 +534,11 @@ xlconfigtest_SOURCES = \
testutils.c testutils.h
 xlconfigtest_LDADD =$(libxl_LDADDS)
 
+xml2sexprtest_SOURCES = \
+   xml2sexprtest.c testutilsxen.c testutilsxen.h \
+   testutils.c testutils.h
+xml2sexprtest_LDADD = $(libxl_LDADDS)
+
 libxlxml2domconfigtest_SOURCES = \
libxlxml2domconfigtest.c testutilsxen.c testutilsxen.h \
testutils.c testutils.h
@@ -550,7 +550,7 @@ virmocklibxl_la_LDFLAGS = $(MOCKLIBS_LDFLAGS)
 virmocklibxl_la_LIBADD = $(MOCKLIBS_LIBS)
 
 else ! WITH_LIBXL
-EXTRA_DIST += xlconfigtest.c libxlxml2domconfigtest.c
+EXTRA_DIST += xlconfigtest.c xml2sexprtest.c libxlxml2domconfigtest.c
 endif ! WITH_LIBXL
 
 QEMUMONITORTESTUTILS_SOURCES = \
diff --git a/tests/xml2sexprdata/xml2sexpr-escape.sexpr 
b/tests/xml2sexprdata/xml2sexpr-escape.sexpr
index 3c2ab8cd2..75411ceb1 100644
--- a/tests/xml2sexprdata/xml2sexpr-escape.sexpr
+++ b/tests/xml2sexprdata/xml2sexpr-escape.sexpr
@@ -5,7 +5,7 @@
 (ramdisk '/var/lib/xen/initrd.img.0u-Vhq')\
 (args ' method=http://download.fedora.devel.redhat.com/pub/fedora/linux/\
 core/test/5.91/x86_64/os="devel"  ')\
-(loader '/usr/lib/xen/boot/hvmloader')(vcpus 2)(boot c)(usb 1)(parallel none)\
+(loader '/usr/lib/xen/boot/hvmloader')(vcpus 2)(boot c)(pae 1)(usb 1)(parallel 
none)\
 (serial pty)(device_model '/usr/lib/xen/bin/qemu-dm')(rtc_timeoffset 0)\
 (localtime 0)))(localtime 0)\
 (device (vbd (dev 'xvda:disk')(uname 'file:/root/\'\\some.img')(mode 'w'
diff --git a/tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr 
b/tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr
index 

[libvirt] [PATCH V2 4/8] Remove xencaps tests and data files

[Jim Fehlig]

Signed-off-by: Jim Fehlig 
---
 tests/Makefile.am  |  20 ---
 tests/testutilsxen.c   |  64 -
 tests/testutilsxen.h   |   2 -
 tests/vircapstest.c|  34 -
 tests/virdrivermoduletest.c|   3 -
 tests/virschematest.c  |   3 +-
 tests/xencapsdata/xen-i686-pae-hvm.caps|   1 -
 tests/xencapsdata/xen-i686-pae-hvm.cpuinfo |  37 -
 tests/xencapsdata/xen-i686-pae-hvm.xml |  49 ---
 tests/xencapsdata/xen-i686-pae.caps|   1 -
 tests/xencapsdata/xen-i686-pae.cpuinfo |  18 ---
 tests/xencapsdata/xen-i686-pae.xml |  32 -
 tests/xencapsdata/xen-i686.caps|   1 -
 tests/xencapsdata/xen-i686.cpuinfo |  18 ---
 tests/xencapsdata/xen-i686.xml |  29 
 tests/xencapsdata/xen-ia64-be-hvm.caps |   1 -
 tests/xencapsdata/xen-ia64-be-hvm.cpuinfo  |  29 
 tests/xencapsdata/xen-ia64-be-hvm.xml  |  45 --
 tests/xencapsdata/xen-ia64-be.caps |   1 -
 tests/xencapsdata/xen-ia64-be.cpuinfo  |  29 
 tests/xencapsdata/xen-ia64-be.xml  |  29 
 tests/xencapsdata/xen-ia64-hvm.caps|   1 -
 tests/xencapsdata/xen-ia64-hvm.cpuinfo |  29 
 tests/xencapsdata/xen-ia64-hvm.xml |  41 --
 tests/xencapsdata/xen-ia64.caps|   1 -
 tests/xencapsdata/xen-ia64.cpuinfo |  29 
 tests/xencapsdata/xen-ia64.xml |  26 
 tests/xencapsdata/xen-ppc64.caps   |   1 -
 tests/xencapsdata/xen-ppc64.cpuinfo|   0
 tests/xencapsdata/xen-ppc64.xml|  26 
 tests/xencapsdata/xen-x86_64-hvm.caps  |   1 -
 tests/xencapsdata/xen-x86_64-hvm.cpuinfo   |  47 --
 tests/xencapsdata/xen-x86_64-hvm.xml   |  61 
 tests/xencapsdata/xen-x86_64.caps  |   1 -
 tests/xencapsdata/xen-x86_64.cpuinfo   |  47 --
 tests/xencapsdata/xen-x86_64.xml   |  29 
 tests/xencapstest.c| 224 -
 37 files changed, 1 insertion(+), 1009 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index e6b85afa6..24dbb56ca 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -161,7 +161,6 @@ EXTRA_DIST = \
virusbtestdata \
vmwareverdata \
vmx2xmldata \
-   xencapsdata \
xlconfigdata \
xmconfigdata \
xml2sexprdata \
@@ -272,10 +271,6 @@ endif WITH_SECDRIVER_SELINUX
 ssh_SOURCES = ssh.c
 ssh_LDADD = $(COVERAGE_LDFLAGS)
 
-if WITH_XEN
-test_programs += xencapstest
-endif WITH_XEN
-
 if WITH_LIBXL
 test_programs += xlconfigtest xml2sexprtest sexpr2xmltest \
xmconfigtest libxlxml2domconfigtest
@@ -498,18 +493,6 @@ sockettest_SOURCES = \
testutils.c testutils.h
 sockettest_LDADD = $(LDADDS)
 
-if WITH_XEN
-xen_LDADDS = ../src/libvirt_driver_xen_impl.la
-xen_LDADDS += $(LDADDS)
-
-xencapstest_SOURCES = \
-   xencapstest.c testutils.h testutils.c
-xencapstest_LDADD = $(xen_LDADDS)
-
-else ! WITH_XEN
-EXTRA_DIST += xencapstest.c testutilsxen.c testutilsxen.h
-endif ! WITH_XEN
-
 if WITH_LIBXL
 libxl_LDADDS = ../src/libvirt_driver_libxl_impl.la
 if WITH_NETWORK
@@ -984,9 +967,6 @@ endif WITH_LXC
 if WITH_QEMU
 vircapstest_SOURCES += testutilsqemu.c testutilsqemu.h
 endif WITH_QEMU
-if WITH_XEN
-vircapstest_SOURCES += testutilsxen.c testutilsxen.h
-endif WITH_XEN
 vircapstest_LDADD = $(qemu_LDADDS) $(LDADDS)
 
 domaincapsmock_la_SOURCES = domaincapsmock.c
diff --git a/tests/testutilsxen.c b/tests/testutilsxen.c
index 4328441b7..c08ec4a6e 100644
--- a/tests/testutilsxen.c
+++ b/tests/testutilsxen.c
@@ -7,70 +7,6 @@
 #include "testutilshostcpus.h"
 #include "domain_conf.h"
 
-virCapsPtr testXenCapsInit(void)
-{
-struct utsname utsname;
-virCapsPtr caps;
-virCapsGuestPtr guest;
-virCapsGuestMachinePtr *machines;
-int nmachines;
-static const char *const x86_machines[] = {
-"xenfv"
-};
-static const char *const xen_machines[] = {
-"xenpv"
-};
-
-uname();
-if ((caps = virCapabilitiesNew(VIR_ARCH_I686,
-   false, false)) == NULL)
-return NULL;
-
-nmachines = ARRAY_CARDINALITY(x86_machines);
-if ((machines = virCapabilitiesAllocMachines(x86_machines, nmachines)) == 
NULL)
-goto cleanup;
-
-if ((guest = virCapabilitiesAddGuest(caps, VIR_DOMAIN_OSTYPE_HVM, 
VIR_ARCH_I686,
- "/usr/lib/xen/bin/qemu-dm", NULL,
- nmachines, machines)) == NULL)
-goto cleanup;
-machines = NULL;
-
-if (virCapabilitiesAddGuestDomain(guest,
-  VIR_DOMAIN_VIRT_XEN,
-  NULL,
-  NULL,
-  0,
-  NULL) == NULL)
-goto cleanup;
-

[libvirt] [PATCH V2 2/8] tests: move sexpr2xml tests to WITH_LIBXL

[Jim Fehlig]

In preparation of removing the legacy Xen driver, move the
sexpr2xml tests from WITH_XEN to WITH_LIBXL. Even though the
legacy driver will be removed, we'll want to maintain the ability
to convert sexpr to XML. Requires fixing up the tests to account
for different behavior of Xen vs libxl post parse functions.

There is some test file fallout due to differences in handling
of default values between xend and libxl.

Signed-off-by: Jim Fehlig 
---
 tests/Makefile.am  | 22 +++---
 tests/sexpr2xmldata/sexpr2xml-boot-grub.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-bridge-ipaddr.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-curmem.xml   |  1 -
 .../sexpr2xml-disk-block-shareable.xml |  1 -
 tests/sexpr2xmldata/sexpr2xml-disk-block.xml   |  3 +-
 .../sexpr2xml-disk-drv-blktap-qcow.xml |  1 -
 .../sexpr2xml-disk-drv-blktap-raw.xml  |  1 -
 .../sexpr2xml-disk-drv-blktap2-raw.xml |  1 -
 tests/sexpr2xmldata/sexpr2xml-disk-file.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml  |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml  |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml|  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml  |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml  |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml  |  7 ++---
 .../sexpr2xml-fv-serial-dev-2-ports.xml|  7 ++---
 .../sexpr2xml-fv-serial-dev-2nd-port.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml|  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml  |  7 ++---
 .../sexpr2xml-fv-serial-tcp-telnet.xml |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml|  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml|  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-sound.xml |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml  |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-utc.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv-v2.xml|  7 ++---
 tests/sexpr2xmldata/sexpr2xml-fv.xml   |  7 ++---
 tests/sexpr2xmldata/sexpr2xml-net-bridged.xml  |  3 +-
 tests/sexpr2xmldata/sexpr2xml-net-e1000.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-net-routed.xml   |  3 +-
 tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml  |  6 ++--
 tests/sexpr2xmldata/sexpr2xml-pci-devs.xml |  5 ++--
 .../sexpr2xml-pv-bootloader-cmdline.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-bootloader.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-localtime.xml |  3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-vcpus.xml |  3 +-
 .../sexpr2xml-pv-vfb-new-vncdisplay.xml|  3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-vfb-new.xml   |  3 +-
 .../sexpr2xmldata/sexpr2xml-pv-vfb-type-crash.xml  |  3 +-
 tests/sexpr2xmldata/sexpr2xml-pv.xml   |  3 +-
 tests/sexpr2xmldata/sexpr2xml-vif-rate.xml |  7 ++---
 tests/sexpr2xmltest.c  | 35 +++---
 51 files changed, 115 insertions(+), 188 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8e48acc69..e27e24fc8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -273,12 +273,12 @@ ssh_SOURCES = ssh.c
 ssh_LDADD = $(COVERAGE_LDFLAGS)
 
 if WITH_XEN
-test_programs += sexpr2xmltest \
-   xmconfigtest xencapstest
+test_programs += xmconfigtest xencapstest
 endif WITH_XEN
 
 if WITH_LIBXL
-test_programs += xlconfigtest xml2sexprtest libxlxml2domconfigtest
+test_programs += xlconfigtest xml2sexprtest sexpr2xmltest \
+   libxlxml2domconfigtest
 test_libraries += virmocklibxl.la
 endif WITH_LIBXL
 
@@ -502,11 +502,6 @@ if WITH_XEN
 xen_LDADDS = ../src/libvirt_driver_xen_impl.la
 xen_LDADDS += $(LDADDS)
 
-sexpr2xmltest_SOURCES = \
-   sexpr2xmltest.c testutilsxen.c testutilsxen.h \
-   testutils.c testutils.h
-sexpr2xmltest_LDADD = $(xen_LDADDS)
-
 xmconfigtest_SOURCES = \
xmconfigtest.c testutilsxen.c testutilsxen.h \
testutils.c testutils.h
@@ -517,8 +512,7 @@ xencapstest_SOURCES = \
 xencapstest_LDADD = $(xen_LDADDS)
 
 else ! WITH_XEN
-EXTRA_DIST += sexpr2xmltest.c xmconfigtest.c \
-   xencapstest.c \
+EXTRA_DIST += xmconfigtest.c xencapstest.c \
testutilsxen.c testutilsxen.h
 endif ! WITH_XEN
 
@@ -539,6 +533,11 @@ xml2sexprtest_SOURCES = \
testutils.c 

[libvirt] [PATCH V2 0/8] Remove the legacy xen driver

[Jim Fehlig]

Long overdue removal the old xen driver. The first 3 patches move existing
tests to WITH_LIBXL since we'll want to continue supporting conversion of
the various xen config formats. The remain patches remove the cruft.

Patch8, new to V2, updates the Xen driver page.

Jim Fehlig (8):
  tests: move xml2sexpr tests to WITH_LIBXL
  tests: move sexpr2xml tests to WITH_LIBXL
  tests: move xmconfig tests to WITH_LIBXL
  Remove xencaps tests and data files
  Remove the xend driver
  docs: remove mention of legacy Xen driver
  spec: remove legacy xen driver
  docs: update Xen driver information

 configure.ac   |7 +-
 docs/architecture.html.in  |   28 +-
 docs/bugs.html.in  |3 +-
 docs/drvxen.html.in|   91 +-
 docs/uri.html.in   |   74 -
 docs/windows.html.in   |2 +-
 libvirt.spec.in|   57 +-
 m4/virt-driver-xen.m4  |  142 -
 po/POTFILES.in |7 -
 src/Makefile.am|1 -
 src/xen/Makefile.inc.am|   67 -
 src/xen/block_stats.c  |  355 ---
 src/xen/block_stats.h  |   38 -
 src/xen/xen_driver.c   | 2845 -
 src/xen/xen_driver.h   |  204 --
 src/xen/xen_hypervisor.c   | 3125 ---
 src/xen/xen_hypervisor.h   |  142 -
 src/xen/xen_inotify.c  |  447 ---
 src/xen/xen_inotify.h  |   33 -
 src/xen/xend_internal.c| 3221 
 src/xen/xend_internal.h|  213 --
 src/xen/xm_internal.c  | 1484 -
 src/xen/xm_internal.h  |  105 -
 src/xen/xs_internal.c  |  920 --
 src/xen/xs_internal.h  |  101 -
 tests/Makefile.am  |   59 +-
 tests/sexpr2xmldata/sexpr2xml-boot-grub.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-bridge-ipaddr.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-curmem.xml   |1 -
 .../sexpr2xml-disk-block-shareable.xml |1 -
 tests/sexpr2xmldata/sexpr2xml-disk-block.xml   |3 +-
 .../sexpr2xml-disk-drv-blktap-qcow.xml |1 -
 .../sexpr2xml-disk-drv-blktap-raw.xml  |1 -
 .../sexpr2xml-disk-drv-blktap2-raw.xml |1 -
 tests/sexpr2xmldata/sexpr2xml-disk-file.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml  |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml  |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml|7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml  |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml  |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml  |7 +-
 .../sexpr2xml-fv-serial-dev-2-ports.xml|7 +-
 .../sexpr2xml-fv-serial-dev-2nd-port.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml|7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml  |7 +-
 .../sexpr2xml-fv-serial-tcp-telnet.xml |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml|7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml|7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-sound.xml |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml  |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-utc.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-fv-v2.xml|7 +-
 tests/sexpr2xmldata/sexpr2xml-fv.xml   |7 +-
 tests/sexpr2xmldata/sexpr2xml-net-bridged.xml  |3 +-
 tests/sexpr2xmldata/sexpr2xml-net-e1000.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-net-routed.xml   |3 +-
 tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml  |6 +-
 tests/sexpr2xmldata/sexpr2xml-pci-devs.xml |5 +-
 .../sexpr2xml-pv-bootloader-cmdline.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-bootloader.xml|3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-localtime.xml |3 +-
 tests/sexpr2xmldata/sexpr2xml-pv-vcpus.xml |3 +-
 

[libvirt] [PATCH V2 7/8] spec: remove legacy xen driver

[Jim Fehlig]

Signed-off-by: Jim Fehlig 
---
 libvirt.spec.in | 57 -
 1 file changed, 4 insertions(+), 53 deletions(-)

diff --git a/libvirt.spec.in b/libvirt.spec.in
index 97143c68a..5090dfa2a 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -18,7 +18,6 @@
 %{!?enable_autotools:%global enable_autotools 0}
 
 # The hypervisor drivers that run in libvirtd
-%define with_xen   0%{!?_without_xen:1}
 %define with_qemu  0%{!?_without_qemu:1}
 %define with_lxc   0%{!?_without_lxc:1}
 %define with_uml   0%{!?_without_uml:1}
@@ -96,7 +95,6 @@
 
 # Xen is available only on i386 x86_64 ia64
 %ifnarch %{ix86} x86_64 ia64
-%define with_xen 0
 %define with_libxl 0
 %endif
 
@@ -161,11 +159,6 @@
 %define with_firewalld 1
 %endif
 
-# RHEL-6 stopped including Xen on all archs.
-%if 0%{?rhel}
-%define with_xen 0
-%endif
-
 # fuse is used to provide virtualized /proc for LXC
 %if %{with_lxc} && 0%{?rhel} != 6
 %define with_fuse  0%{!?_without_fuse:1}
@@ -280,9 +273,6 @@ Requires: libvirt-daemon-driver-qemu = %{version}-%{release}
 %if %{with_uml}
 Requires: libvirt-daemon-driver-uml = %{version}-%{release}
 %endif
-%if %{with_xen}
-Requires: libvirt-daemon-driver-xen = %{version}-%{release}
-%endif
 %if %{with_vbox}
 Requires: libvirt-daemon-driver-vbox = %{version}-%{release}
 %endif
@@ -316,7 +306,7 @@ BuildRequires: %{python}
 %if %{with_systemd}
 BuildRequires: systemd-units
 %endif
-%if %{with_xen} || %{with_libxl}
+%if %{with_libxl}
 BuildRequires: xen-devel
 %endif
 BuildRequires: libxml2-devel
@@ -376,11 +366,6 @@ BuildRequires: util-linux
 BuildRequires: libacl-devel
 # From QEMU RPMs
 BuildRequires: /usr/bin/qemu-img
-%else
-%if %{with_xen}
-# From Xen RPMs
-BuildRequires: /usr/sbin/qcow-create
-%endif
 %endif
 # For LVM drivers
 BuildRequires: lvm2
@@ -634,11 +619,6 @@ Requires: util-linux
 %if %{with_qemu}
 # From QEMU RPMs
 Requires: /usr/bin/qemu-img
-%else
-%if %{with_xen}
-# From Xen RPMs
-Requires: /usr/sbin/qcow-create
-%endif
 %endif
 
 %description daemon-driver-storage-core
@@ -843,19 +823,6 @@ User Mode Linux
 %endif
 
 
-%if %{with_xen}
-%package daemon-driver-xen
-Summary: Xen driver plugin for the libvirtd daemon
-Group: Development/Libraries
-Requires: libvirt-daemon = %{version}-%{release}
-
-%description daemon-driver-xen
-The Xen driver plugin for the libvirtd daemon, providing
-an implementation of the hypervisor driver APIs using
-Xen
-%endif
-
-
 %if %{with_vbox}
 %package daemon-driver-vbox
 Summary: VirtualBox driver plugin for the libvirtd daemon
@@ -966,15 +933,12 @@ capabilities of UML
 %endif
 
 
-%if %{with_xen} || %{with_libxl}
+%if %{with_libxl}
 %package daemon-xen
 Summary: Server side daemon & driver required to run XEN guests
 Group: Development/Libraries
 
 Requires: libvirt-daemon = %{version}-%{release}
-%if %{with_xen}
-Requires: libvirt-daemon-driver-xen = %{version}-%{release}
-%endif
 %if %{with_libxl}
 Requires: libvirt-daemon-driver-libxl = %{version}-%{release}
 %endif
@@ -1169,12 +1133,6 @@ echo "This RPM requires either Fedora >= %{min_fedora} 
or RHEL >= %{min_rhel}"
 exit 1
 %endif
 
-%if %{with_xen}
-%define arg_xen --with-xen
-%else
-%define arg_xen --without-xen
-%endif
-
 %if %{with_qemu}
 %define arg_qemu --with-qemu
 %else
@@ -1342,8 +1300,7 @@ export SOURCE_DATE_EPOCH=$(stat --printf='%Y' 
%{_specdir}/%{name}.spec)
 %endif
 
 rm -f po/stamp-po
-%configure %{?arg_xen} \
-   %{?arg_qemu} \
+%configure %{?arg_qemu} \
%{?arg_openvz} \
%{?arg_lxc} \
%{?arg_vbox} \
@@ -2002,12 +1959,6 @@ exit 0
 %{_libdir}/%{name}/connection-driver/libvirt_driver_uml.so
 %endif
 
-%if %{with_xen}
-%files daemon-driver-xen
-%dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/xen/
-%{_libdir}/%{name}/connection-driver/libvirt_driver_xen.so
-%endif
-
 %if %{with_libxl}
 %files daemon-driver-libxl
 %config(noreplace) %{_sysconfdir}/libvirt/libxl.conf
@@ -2042,7 +1993,7 @@ exit 0
 %files daemon-uml
 %endif
 
-%if %{with_xen} || %{with_libxl}
+%if %{with_libxl}
 %files daemon-xen
 %endif
 
-- 
2.16.3

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

[libvirt] [PATCH V2 6/8] docs: remove mention of legacy Xen driver

[Jim Fehlig]

Signed-off-by: Jim Fehlig 
---

V2: Fix small typo

 docs/architecture.html.in | 28 --
 docs/bugs.html.in |  3 +-
 docs/uri.html.in  | 74 ---
 docs/windows.html.in  |  2 +-
 4 files changed, 9 insertions(+), 98 deletions(-)

diff --git a/docs/architecture.html.in b/docs/architecture.html.in
index 5e5671661..7a5cf2dca 100644
--- a/docs/architecture.html.in
+++ b/docs/architecture.html.in
@@ -19,32 +19,16 @@
 in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
 kernel provides most if not all of the actual drivers used by the set of
 domains. It also runs the Xen Store, a database of information shared by the
-hypervisor, the kernels, the drivers and the xen daemon. Xend. The xen daemon
-supervise the control and execution of the sets of domains. The hypervisor,
+hypervisor, the backend drivers, any running domains, and libxl (aka 
libxenlight).
+libxl provides a set of APIs for creating and managing domains, which can be 
used
+by applications such as the xl tool provided by Xen or libvirt. The hypervisor,
 drivers, kernels and daemons communicate though a shared system bus
 implemented in the hypervisor. The figure below tries to provide a view of
 this environment:
 
-The library can be initialized in 2 ways depending on the level of
-privilege of the embedding program. If it runs with root access,
-virConnectOpen() can be used, it will use three different ways to connect to
-the Xen infrastructure:
-
-  a connection to the Xen Daemon though an HTTP RPC layer
-  a read/write connection to the Xen Store
-  use Xen Hypervisor calls
-  when used as non-root libvirt connect to a proxy daemon running
-  as root and providing read-only support
-
-The library will usually interact with the Xen daemon for any operation
-changing the state of the system, but for performance and accuracy reasons
-may talk directly to the hypervisor when gathering state information at
-least when possible (i.e. when the running program using libvirt has root
-privilege access).
-If it runs without root access virConnectOpenReadOnly() should be used 
to
-connect to initialize the library. It will then fork a libvirt_proxy
-program running as root and providing read_only access to the API, this is
-then only useful for reporting and monitoring.
+The library will interact with libxl for all management operations
+on a Xen system.
+Note that the libvirt libxl driver only supports root access.
 
 QEMU and KVM support
 
diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 12a1090c1..553422338 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -122,7 +122,8 @@
   The hardware architecture being used
   The name of the hypervisor (Xen, QEMU, KVM)
   The XML config of the guest domain if relevant
-  For Xen hypervisor, the XenD logfile from /var/log/xen
+  For Xen hypervisor, the domain logfiles from /var/log/xen and
+  /var/log/libvirt/libxl
   For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu
 
 
diff --git a/docs/uri.html.in b/docs/uri.html.in
index ade726089..5df73613a 100644
--- a/docs/uri.html.in
+++ b/docs/uri.html.in
@@ -253,59 +253,6 @@ the user to type a URI in directly (if that is 
appropriate).  If your
 application wishes to connect specifically to a Xen hypervisor, then
 for future proofing it should choose a full xen:/// URI.
 
-
-  File paths (xend-unix-server)
-
-
-If XenD is running and configured in /etc/xen/xend-config.sxp:
-
-
-(xend-unix-server yes)
-
-
-then it listens on a Unix domain socket, usually at
-/var/lib/xend/xend-socket.  You may pass a different path
-using a file URI such as:
-
-
-virsh -c ///var/run/xend/xend-socket
-
-
-  Legacy: http://... (xend-http-server)
-
-
-If XenD is running and configured in /etc/xen/xend-config.sxp:
-
-
-
-(xend-http-server yes)
-
-
-then it listens on TCP port 8000.  libvirt allows you to
-try to connect to xend running on remote machines by passing
-http://hostname[:port]/, for example:
-
-
-
-virsh -c http://oirase/ list
-
-
-This method is unencrypted and insecure and is definitely not
-recommended for production use.  Instead use libvirt's 
remote support.
-
-
-Notes:
-
-
-   The HTTP client does not fully support IPv6. 
-   Many features do not work as expected across HTTP connections, in
- particular, virConnectGetCapabilities.
- The remote support however does work
- correctly. 
-   XenD's new-style XMLRPC interface is not supported by
- libvirt, only the old-style sexpr interface known in the Xen
- documentation as "unix server" or "http server".
-
 
   Legacy: "xen"
 
@@ -313,27 +260,6 @@ Notes:
 Another legacy URI is to specify name as the string
 "xen".  This will continue to refer to the Xen
 hypervisor.  However you should prefer a full 

[libvirt] [PATCH V2 8/8] docs: update Xen driver information

[Jim Fehlig]

Now that the old Xen driver is removed, update the drvxen
page with current information on the libxl drvier and remove
all the old cruft.

Signed-off-by: Jim Fehlig 
---

New patch in V2 to update the Xen driver page.

 docs/drvxen.html.in | 91 +
 1 file changed, 35 insertions(+), 56 deletions(-)

diff --git a/docs/drvxen.html.in b/docs/drvxen.html.in
index d30ed2a04..b8d190c94 100644
--- a/docs/drvxen.html.in
+++ b/docs/drvxen.html.in
@@ -2,20 +2,20 @@
 
 http://www.w3.org/1999/xhtml;>
   
-Xen hypervisor driver
+libxl hypervisor driver for Xen
 
 
 
 
-  The libvirt Xen driver provides the ability to manage virtual machines
-  on any Xen release from 3.0.1 onwards.
+  The libvirt libxl driver provides the ability to manage virtual
+  machines on any Xen release from 4.4.0 onwards.
 
 
 Project Links
 
 
   
-The http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html;>Xen
+The https://www.xenproject.org;>Xen
 hypervisor on Linux and Solaris hosts
   
 
@@ -23,54 +23,23 @@
 Deployment pre-requisites
 
 
-  The libvirt Xen driver uses a combination of channels to manage Xen
-  virtual machines.
+  The libvirt libxl driver uses Xen's libxl API, also known as
+  libxenlight, to implement libvirt's hypervisor driver
+  functionality. libxl provides a consolidated interface for
+  managing a Xen host and its virtual machines, unlike old
+  versions of Xen where applications often had to communicate
+  with xend, xenstored, and the hypervisor itself via hypercalls.
+  With libxl the only pre-requisit is a properly installed Xen
+  host with the libxl toolstack running in a service domain
+  (often Domain-0).
 
 
-
-  
-XenD: Access to the Xen daemon is a mandatory
-requirement for the libvirt Xen driver. It requires that the UNIX
-socket interface be enabled in the 
/etc/xen/xend-config.sxp
-configuration file. Specifically the config settings
-(xend-unix-server yes). This path is usually restricted
-to only allow the root user access. As an alternative,
-the HTTP interface can be used, however, this has significant security
-implications.
-  
-  
-XenStoreD: Access to the Xenstore daemon enables
-more efficient codepaths for looking up domain information which
-lowers the CPU overhead of management.
-  
-  
-Hypercalls: The ability to make direct hypercalls
-allows the most efficient codepaths in the driver to be used for
-monitoring domain status.
-  
-  
-XM config: When using Xen releases prior to 3.0.4,
-there is no inactive domain management in XenD. For such releases,
-libvirt will automatically process XM configuration files kept in
-the /etc/xen directory. It is important not to place
-any other non-config files in this directory.
-  
-  
-libxl: Starting with Xen 4.2, the legacy XenD/xm
-toolstack is deprecated in favor of libxl, also commonly called
-libxenlight.  libvirt supports this new Xen toolstack via the
-libxl driver.  If XenD is enabled, the legacy xen driver consisting
-of the above mentioned channels will be used.  If XenD is disabled,
-the libxl driver will be used.
-  
-
-
-Connections to Xen driver
+Connections to libxl driver
 
 
-The libvirt Xen driver is a single-instance privileged driver,
-with a driver name of 'xen'. Some example connection URIs for
-the libvirt driver are:
+  The libvirt libxl driver is a single-instance privileged driver,
+  with a driver name of 'xen'. Some example connection URIs for
+  the libxl driver are:
 
 
 
@@ -83,18 +52,28 @@ xen+ssh://r...@example.com/(remote access, SSH 
tunnelled)
 
 Import and export of libvirt domain XML configs
 
-The Xen driver currently supports two native
-  config formats. The first known as xen-xm is the format
-  used by the XM tool for files in /etc/xen. The second
-  known as xen-sxpr, is the format used for interacting
-  with the XenD's legacy HTTP RPC service.
+
+  The libxl driver currently supports three native
+  config formats. The first, known as xen-xm, is the
+  original Xen virtual machine config format used by the legacy
+  xm/xend toolstack. The second, known as xen-sxpr,
+  is also one of the original formats that was used by xend's
+  legacy HTTP RPC service. For compatibility, import and export
+  of these legacy formats is supported by the libxl driver.
+
+
+
+  The third format is xen-xl, which is the virtual
+  machine config format supported by modern Xen. The xen-xl
+  format is described in the xl.cfg(5) man page.
+
 
 

[libvirt] [PATCH V2 3/8] tests: move xmconfig tests to WITH_LIBXL

[Jim Fehlig]

In preparation of removing the legacy Xen driver, move the
xmconfig tests from WITH_XEN to WITH_LIBXL. Even though the
legacy driver will be removed, we'll want to maintain the ability
to convert xm config to XML. Requires fixing up the tests to account
for different behavior of Xen vs libxl post parse functions. For
consistency with other Xen config tests, change the  arch to
x86_64.

There is some test file fallout due to differences in handling of
default values between xend and libxl.

Signed-off-by: Jim Fehlig 
---
 tests/Makefile.am  | 19 +--
 tests/xmconfigdata/test-disk-drv-blktap-raw.xml|  3 +--
 tests/xmconfigdata/test-disk-drv-blktap2-raw.xml   |  3 +--
 tests/xmconfigdata/test-escape-paths.xml   | 11 +--
 .../xmconfigdata/test-fullvirt-default-feature.xml |  9 -
 tests/xmconfigdata/test-fullvirt-force-hpet.xml|  9 -
 tests/xmconfigdata/test-fullvirt-force-nohpet.xml  |  9 -
 tests/xmconfigdata/test-fullvirt-localtime.xml |  9 -
 tests/xmconfigdata/test-fullvirt-net-netfront.xml  |  9 -
 tests/xmconfigdata/test-fullvirt-new-cdrom.xml |  9 -
 tests/xmconfigdata/test-fullvirt-nohap.xml |  9 -
 tests/xmconfigdata/test-fullvirt-parallel-tcp.xml  |  9 -
 tests/xmconfigdata/test-fullvirt-serial-file.xml   |  9 -
 tests/xmconfigdata/test-fullvirt-serial-null.xml   |  9 -
 tests/xmconfigdata/test-fullvirt-serial-pipe.xml   |  9 -
 tests/xmconfigdata/test-fullvirt-serial-pty.xml|  9 -
 tests/xmconfigdata/test-fullvirt-serial-stdio.xml  |  9 -
 .../test-fullvirt-serial-tcp-telnet.xml|  9 -
 tests/xmconfigdata/test-fullvirt-serial-tcp.xml|  9 -
 tests/xmconfigdata/test-fullvirt-serial-udp.xml|  9 -
 tests/xmconfigdata/test-fullvirt-serial-unix.xml   |  9 -
 tests/xmconfigdata/test-fullvirt-sound.xml |  9 -
 tests/xmconfigdata/test-fullvirt-usbmouse.xml  |  9 -
 tests/xmconfigdata/test-fullvirt-usbtablet.xml |  9 -
 tests/xmconfigdata/test-fullvirt-utc.xml   |  9 -
 tests/xmconfigdata/test-no-source-cdrom.xml|  9 -
 tests/xmconfigdata/test-paravirt-maxvcpus.xml  |  5 ++---
 tests/xmconfigdata/test-paravirt-net-e1000.xml |  5 ++---
 tests/xmconfigdata/test-paravirt-net-vifname.xml   |  5 ++---
 .../test-paravirt-new-pvfb-vncdisplay.xml  |  5 ++---
 tests/xmconfigdata/test-paravirt-new-pvfb.xml  |  5 ++---
 tests/xmconfigdata/test-paravirt-vcpu.xml  |  5 ++---
 tests/xmconfigdata/test-pci-devs.xml   | 11 ++-
 tests/xmconfigtest.c   | 22 +++---
 34 files changed, 125 insertions(+), 172 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index e27e24fc8..e6b85afa6 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -273,12 +273,12 @@ ssh_SOURCES = ssh.c
 ssh_LDADD = $(COVERAGE_LDFLAGS)
 
 if WITH_XEN
-test_programs += xmconfigtest xencapstest
+test_programs += xencapstest
 endif WITH_XEN
 
 if WITH_LIBXL
 test_programs += xlconfigtest xml2sexprtest sexpr2xmltest \
-   libxlxml2domconfigtest
+   xmconfigtest libxlxml2domconfigtest
 test_libraries += virmocklibxl.la
 endif WITH_LIBXL
 
@@ -502,18 +502,12 @@ if WITH_XEN
 xen_LDADDS = ../src/libvirt_driver_xen_impl.la
 xen_LDADDS += $(LDADDS)
 
-xmconfigtest_SOURCES = \
-   xmconfigtest.c testutilsxen.c testutilsxen.h \
-   testutils.c testutils.h
-xmconfigtest_LDADD = $(xen_LDADDS)
-
 xencapstest_SOURCES = \
xencapstest.c testutils.h testutils.c
 xencapstest_LDADD = $(xen_LDADDS)
 
 else ! WITH_XEN
-EXTRA_DIST += xmconfigtest.c xencapstest.c \
-   testutilsxen.c testutilsxen.h
+EXTRA_DIST += xencapstest.c testutilsxen.c testutilsxen.h
 endif ! WITH_XEN
 
 if WITH_LIBXL
@@ -538,6 +532,11 @@ sexpr2xmltest_SOURCES = \
testutils.c testutils.h
 sexpr2xmltest_LDADD = $(libxl_LDADDS)
 
+xmconfigtest_SOURCES = \
+   xmconfigtest.c testutilsxen.c testutilsxen.h \
+   testutils.c testutils.h
+xmconfigtest_LDADD = $(libxl_LDADDS)
+
 libxlxml2domconfigtest_SOURCES = \
libxlxml2domconfigtest.c testutilsxen.c testutilsxen.h \
testutils.c testutils.h
@@ -550,7 +549,7 @@ virmocklibxl_la_LIBADD = $(MOCKLIBS_LIBS)
 
 else ! WITH_LIBXL
 EXTRA_DIST += xlconfigtest.c xml2sexprtest.c sexpr2xmltest.c \
-   libxlxml2domconfigtest.c
+   xmconfigtest.c libxlxml2domconfigtest.c
 endif ! WITH_LIBXL
 
 QEMUMONITORTESTUTILS_SOURCES = \
diff --git a/tests/xmconfigdata/test-disk-drv-blktap-raw.xml 
b/tests/xmconfigdata/test-disk-drv-blktap-raw.xml
index cf859bad9..b8a1eafdd 100644
--- a/tests/xmconfigdata/test-disk-drv-blktap-raw.xml
+++ b/tests/xmconfigdata/test-disk-drv-blktap-raw.xml
@@ -6,7 +6,7 @@
   2
   /usr/bin/pygrub
   
-linux
+linux
   
   
   destroy
@@ -28,6 +28,5 @@

Re: [libvirt] [PATCH 1/4] conf: Use virDomainChrSourceDefNew for vhostuser

[Eric Blake]

On 04/06/2018 01:31 PM, Laine Stump wrote:
> On 04/06/2018 12:53 PM, John Ferlan wrote:
>> Rather than using VIR_ALLOC, use the New API since we already
>> use the virDomainChrSourceDefFree function when done.
>>

>> -if (VIR_ALLOC(def->data.vhostuser) < 0)
>> +if (!(def->data.vhostuser = virDomainChrSourceDefNew(xmlopt)))
>>  goto error;
>>  
>>  def->data.vhostuser->type = VIR_DOMAIN_CHR_TYPE_UNIX;
> 
> 
> Reviewed-by: Laine Stump 
> 
> 
> There have been cases in the past where a *New() or *Free() function was
> added but not consistently used, leading to leaks or (worse, but at
> least easier to detect) crashes due to null pointer dereferences. It
> would really be nice if there was some way to automate the auditing of
> all the VIR_ALLOCs, but I don't think it's possible with the simple make
> syntax-check target (that's supposed to be a challenge to someone :-),
> and there's 1223 uses of VIR_ALLOC() (6421 of VIR_FREE()), so even a one
> time manual audit is really out of the question (and the results would
> be immediately obsolete as soon as a new VIR_ALLOC or VIR_FREE was added).

I wonder - is there some way we could automate the auditing, perhaps in
a debug-only mode, by expanding the VIR_ALLOC() macro to do a giant
compile-time blacklist using a chain of gcc's __builtin_choose_expr()
and __builtin_types_compatible_p(ptr, BadType) to forbid direct use of
VIR_ALLOC() on any type we add to the blacklist chain.  Meanwhile, we'd
have to add a new variant of VIR_ALLOC() for use within call sites like
virDomainChrSourceDevNew(), that are performing the actual allocation
for any type that is otherwise blacklisted (and where it is easier to
audit that calls to the new macro are really limited to the constructor
functions of those blacklisted types).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [libvirt] [PATCH 2/4] qemu: Use virDomainChrSourceDefNew for monConfig

[Laine Stump]

On 04/06/2018 12:53 PM, John Ferlan wrote:
> Rather than VIR_ALLOC, use the New function for allocation. We
> already use the Free function anyway.
>
> Signed-off-by: John Ferlan 
> ---
>  src/conf/domain_conf.c   | 2 +-
>  src/conf/domain_conf.h   | 3 +++
>  src/libvirt_private.syms | 1 +
>  src/qemu/qemu_domain.c   | 2 +-
>  src/qemu/qemu_process.c  | 2 +-
>  5 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index caf3f47c63..fd57364cd4 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -12211,7 +12211,7 @@ 
> virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def,
>  }
>  
>  
> -static virDomainChrSourceDefPtr
> +virDomainChrSourceDefPtr
>  virDomainChrSourceDefNew(virDomainXMLOptionPtr xmlopt)
>  {
>  virDomainChrSourceDefPtr def = NULL;
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index 68473c309e..89a7131fdb 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -2827,6 +2827,9 @@ bool virDomainDefHasDeviceAddress(virDomainDefPtr def,
>  
>  void virDomainDefFree(virDomainDefPtr vm);
>  
> +virDomainChrSourceDefPtr
> +virDomainChrSourceDefNew(virDomainXMLOptionPtr xmlopt);
> +
>  virDomainChrDefPtr virDomainChrDefNew(virDomainXMLOptionPtr xmlopt);
>  
>  virDomainDefPtr virDomainDefNew(void);
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index c550310cc0..cab324c4d7 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -218,6 +218,7 @@ virDomainChrSourceDefClear;
>  virDomainChrSourceDefCopy;
>  virDomainChrSourceDefFree;
>  virDomainChrSourceDefGetPath;
> +virDomainChrSourceDefNew;
>  virDomainChrSpicevmcTypeFromString;
>  virDomainChrSpicevmcTypeToString;
>  virDomainChrTcpProtocolTypeFromString;
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index f03aa03e8a..bdc6e58d6e 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -2422,7 +2422,7 @@ qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt,
>  xmlNodePtr node = NULL;
>  virQEMUCapsPtr qemuCaps = NULL;
>  
> -if (VIR_ALLOC(priv->monConfig) < 0)
> +if (!(priv->monConfig = virDomainChrSourceDefNew(NULL)))
>  goto error;
>  
>  if (!(monitorpath =
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index c0105c8b84..a8dab92dd6 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -5717,7 +5717,7 @@ qemuProcessPrepareDomain(virQEMUDriverPtr driver,
>  goto cleanup;
>  }
>  
> -if (VIR_ALLOC(priv->monConfig) < 0)
> +if (!(priv->monConfig = virDomainChrSourceDefNew(NULL)))
>  goto cleanup;
>  
>  VIR_DEBUG("Preparing monitor state");


It's a bit obscure to get to, but qemu_parse_command.c:2487 has a
VIR_ALLOC(chr) that ends up being put into a monConfig - you'll need to
change that one to use virDomainChrSourceDefNew() to be complete. If you
do that, then:


Reviewed-by: Laine Stump 

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

Re: [libvirt] [PATCH 1/4] conf: Use virDomainChrSourceDefNew for vhostuser

[Laine Stump]

On 04/06/2018 12:53 PM, John Ferlan wrote:
> Rather than using VIR_ALLOC, use the New API since we already
> use the virDomainChrSourceDefFree function when done.
>
> Signed-off-by: John Ferlan 
> ---
>  src/conf/domain_conf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index aacd06a87a..caf3f47c63 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -11138,7 +11138,7 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt,
>  goto error;
>  }
>  
> -if (VIR_ALLOC(def->data.vhostuser) < 0)
> +if (!(def->data.vhostuser = virDomainChrSourceDefNew(xmlopt)))
>  goto error;
>  
>  def->data.vhostuser->type = VIR_DOMAIN_CHR_TYPE_UNIX;


Reviewed-by: Laine Stump 


There have been cases in the past where a *New() or *Free() function was
added but not consistently used, leading to leaks or (worse, but at
least easier to detect) crashes due to null pointer dereferences. It
would really be nice if there was some way to automate the auditing of
all the VIR_ALLOCs, but I don't think it's possible with the simple make
syntax-check target (that's supposed to be a challenge to someone :-),
and there's 1223 uses of VIR_ALLOC() (6421 of VIR_FREE()), so even a one
time manual audit is really out of the question (and the results would
be immediately obsolete as soon as a new VIR_ALLOC or VIR_FREE was added).

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

Re: [libvirt] [PATCH 03/11] conf: Remove dubious code from virDomainPCIAddressSetGrow()

[Laine Stump]

On 04/04/2018 04:54 AM, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 22:44 -0400, Laine Stump wrote:
>
>> In the meantime, if I remove that code (and don't apply any of your
>> patches) then a pure pcie domain *can* be successfully edited to add a
>> single pci-bridge (as long as you specify an index, *and* there is an
>> unused index of a smaller value), but what ends up in the
>> "proper/validated" config is a pci-bridge that is plugged directly into
>> a pcie-root-port (which is also wrong, but silently so).
>>
>> So I guess I reserve my judgement until I see what happens with your
>> entire series applied, which I'll do tomorrow morning.
> Looking forward to that :)
>

So it turns out that once all of your patches are applied, the error is
the same before or after this code is removed, so I think it may not be
executed at all.


Since it doesn't solve the issue it originally was intended to solve,
and removing it makes no functional difference, I have no problem with
you removing it (it would be nice if we could figure out a way to log a
more informative error than:


    unsupported configuration: PCI controller at index 4 (0x04) has
bus='0x04',

    but index must be larger than bus


but that's a separate issue.)

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

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

[Laszlo Ersek]

On 04/06/18 20:10, Eric Blake wrote:
> On 04/06/2018 12:28 PM, Laszlo Ersek wrote:
>
>> I've created an RFC-level "qapi/firmware.json" schema file, based on
>> this discussion. It "builds", and the generated documentation looks
>> acceptable, superficially speaking.
>>
>> Before I post "qapi/firmware.json" for getting comments, I'd like to
>> write JSON text that (a) describes firmware that I use, and (b)
>> conforms to the schema. IOW, I'd like to validate whether the schema
>> is good enough for describing at least such firmware that I know.
>>
>> Is there a tool that generates example JSON objects from a given
>> schema?
>
> I know the QMP shell (scripts/qmp/qmp-shell) lets you enter commands
> with a lot less typing than full JSON, and has a mode where it will
> then echo the full JSON command it constructed from what you typed. To
> be able to quickly validate examples, it may be sufficient to
> temporarily add a new QMP command 'check-firmware':
>
> { 'command': 'check-firmware', 'boxed': true, 'data': 'Firmware' }
>
> assuming 'Firmware' is your top-level 'struct' in the QAPI file, then
> implement a trivial:
>
> qmp_check_firmware(Firmware *obj, Error **errp) {
> return 0;
> }
>
> so that you can then run QMP shell, and type:
>
> check-firmware arg1=foo arg2=bar ...
>
> which will then generate the corresponding JSON, then either
> successfully do nothing (what you typed validated, AND you have the
> JSON output printed), or print an error (what you typed failed QAPI
> validation, perhaps because it had an unrecognized key, was missing a
> required key, used a wrong type, etc).
>
>> I vaguely recall there used to be one. Otherwise, writing the
>> examples manually looks arduous (and I wouldn't know how to verify
>> them against the schema).
>
> Similarly, if you generate a command the produces a 'Firmware' as the
> return value, then you can populate the generated C struct (since you
> did manage to run the QAPI generator over your new file, you should be
> able to look at the C struct it generated), then output that over QMP
> to show the counterpart JSON that matches the struct as populated.
>

The top level structure is complex / nested, but that doesn't appear to
be an issue. According to the script,

# key=value pairs also support Python or JSON object literal subset notations,
# without spaces. Dictionaries/objects {} are supported as are arrays [].
#
#example-command arg-name1={'key':'value','obj'={'prop':"value"}}
#
# Both JSON and Python formatting should work, including both styles of
# string literal quotes. Both paradigms of literal values should work,
# including null/true/false for JSON and None/True/False for Python.

This looks awesome, because it should let me provide messy nested input
(which I'll obviously compose in my $EDITOR and then paste it), and then
the QMP shell will both validate and pretty print that. I'm going to try
this.

Thank you, Eric!
Laszlo

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

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

[Eric Blake]

On 04/06/2018 12:28 PM, Laszlo Ersek wrote:

> I've created an RFC-level "qapi/firmware.json" schema file, based on
> this discussion. It "builds", and the generated documentation looks
> acceptable, superficially speaking.
> 
> Before I post "qapi/firmware.json" for getting comments, I'd like to
> write JSON text that (a) describes firmware that I use, and (b) conforms
> to the schema. IOW, I'd like to validate whether the schema is good
> enough for describing at least such firmware that I know.
> 
> Is there a tool that generates example JSON objects from a given schema?

I know the QMP shell (scripts/qmp/qmp-shell) lets you enter commands
with a lot less typing than full JSON, and has a mode where it will then
echo the full JSON command it constructed from what you typed.  To be
able to quickly validate examples, it may be sufficient to temporarily
add a new QMP command 'check-firmware':

{ 'command': 'check-firmware', 'boxed': true, 'data': 'Firmware' }

assuming 'Firmware' is your top-level 'struct' in the QAPI file, then
implement a trivial:

qmp_check_firmware(Firmware *obj, Error **errp) {
return 0;
}

so that you can then run QMP shell, and type:

check-firmware arg1=foo arg2=bar ...

which will then generate the corresponding JSON, then either
successfully do nothing (what you typed validated, AND you have the JSON
output printed), or print an error (what you typed failed QAPI
validation, perhaps because it had an unrecognized key, was missing a
required key, used a wrong type, etc).

> I vaguely recall there used to be one. Otherwise, writing the examples
> manually looks arduous (and I wouldn't know how to verify them against
> the schema).

Similarly, if you generate a command the produces a 'Firmware' as the
return value, then you can populate the generated C struct (since you
did manage to run the QAPI generator over your new file, you should be
able to look at the C struct it generated), then output that over QMP to
show the counterpart JSON that matches the struct as populated.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [libvirt] [PATCH 3/4] conf: Introduce virDomainObjListAddObjLocked

[John Ferlan]

On 04/06/2018 08:56 AM, Michal Privoznik wrote:
> On 03/29/2018 02:34 PM, John Ferlan wrote:
>> Create a common helper to add an object to the locked domain
>> objlist hash tables and use it.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  src/conf/virdomainobjlist.c | 64 
>> +++--
>>  1 file changed, 39 insertions(+), 25 deletions(-)
>>
>> diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c
>> index 765f46d5a..7022abe09 100644
>> --- a/src/conf/virdomainobjlist.c
>> +++ b/src/conf/virdomainobjlist.c
>> @@ -220,6 +220,42 @@ virDomainObjPtr 
>> virDomainObjListFindByName(virDomainObjListPtr doms,
>>  }
>>  
>>  
>> +/**
>> + * @doms: Domain object list pointer
>> + * @vm: Domain object to be added
>> + *
>> + * Upon entry @vm should have at least 1 ref and be locked.
>> + *
>> + * Add the @vm into the @doms->objs and @doms->objsName hash
>> + * tables.
>> + *
>> + * Returns 0 on success with 2 references and locked
>> + *-1 on failure with 1 reference and locked
>> + */
>> +static int
>> +virDomainObjListAddObjLocked(virDomainObjListPtr doms,
>> + virDomainObjPtr vm)
>> +{
>> +char uuidstr[VIR_UUID_STRING_BUFLEN];
>> +
>> +virUUIDFormat(vm->def->uuid, uuidstr);
>> +if (virHashAddEntry(doms->objs, uuidstr, vm) < 0)
>> +return -1;
>> +
>> +if (virHashAddEntry(doms->objsName, vm->def->name, vm) < 0) {
>> +virObjectRef(vm);
>> +virHashRemoveEntry(doms->objs, uuidstr);
>> +return -1;
>> +}
>> +
>> +/* Since domain is in two hash tables, increment the
>> + * reference counter */
>> +virObjectRef(vm);
> 
> I think this virObjectRef() could be moved in between those two
> virHashAddEntry() calls and thus the later call to virObjectRef() can be
> dropped then.
> 

True; however, the purpose of the first two patches was to set the code
up to mirror each other and thus have this helper instead do the same
thing. The reality is the next step *is* to put a virObjectRef between
the two and thus have 2 virObjectRef calls to match the 2 Unref calls in
the *Remove function.  The next step also removes the comment leaving an
ObjectRef after each successful AddEntry.

Doing this means "some" drivers won't need the extra virObjectRef after
they call the Add function, while "other" drivers will need to use the
Remove and EndAPI after they call the Add function.

I've been trying to coordinate this effort with the FindBy{UUID|ID}[Ref]
effort as they are (in a way) strangely related.

Tks-

John

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

Re: [libvirt] [PATCH 1/4] conf: Fix error path logic in virDomainObjListAddLocked

[John Ferlan]

On 04/06/2018 08:56 AM, Michal Privoznik wrote:
> On 03/29/2018 02:34 PM, John Ferlan wrote:
>> If the virHashAddEntry fails, then we need to "careful" about
>> how we free the @vm. When virDomainObjNew returns there is one
>> reference and the object is locked, so use virDomainObjEndAPI
>> when done.
>>
>> Add a virObjectRef in the error path for the second virHashAddEntry
>> call since it doesn't call virObjectRef, but virHashRemoveEntry
>> will call virObjectUnref because virObjectFreeHashData is called
>> when the element is removed from the hash table as set up in
>> virDomainObjListNew.
>>
>> Eventually these paths should goto error and error should be changed
>> to use EndAPI as well, but that requires more adjustments to other
>> paths in the code to have a locked and ref counted @vm.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  src/conf/virdomainobjlist.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c
>> index 87a742b1e..2ae8a41a1 100644
>> --- a/src/conf/virdomainobjlist.c
>> +++ b/src/conf/virdomainobjlist.c
>> @@ -296,12 +296,14 @@ virDomainObjListAddLocked(virDomainObjListPtr doms,
>>  
>>  virUUIDFormat(def->uuid, uuidstr);
>>  if (virHashAddEntry(doms->objs, uuidstr, vm) < 0) {
>> -virObjectUnref(vm);
>> +virObjectEndAPI();
> 
> s/virObjectEndAPI/virDomainObjEndAPI/ here and down too ;-)
> 

Oh right - good catch... obviously I worked backwards from patch 3 but
my fingers mistyped things

Fixed...

Tks,

John

>>  return NULL;
>>  }
>>  
>>  if (virHashAddEntry(doms->objsName, def->name, vm) < 0) {
>> +virObjectRef(vm);
>>  virHashRemoveEntry(doms->objs, uuidstr);
>> +virObjectEndAPI();
>>  return NULL;
>>  }
>>  
>>
> 
> ACK
> 
> Michal
> 

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

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

[Laszlo Ersek]

On 03/08/18 11:17, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote:
>>   Hi,
>>
 [*] Open question: Who, between QEMU and libvirt, should define the said
 firmware metadata format and file?
>>>
>>> IMHO QEMU should be defining the format, because the file will contain
>>> info about certain QEMU features associated with the firmware (eg smm).
>>> Also there are potentially other non-libvirt mgmt apps that spawn QEMU
>>> which would like this info (eg libguestfs), so having libvirt define the
>>> format is inappropriate.
>>>
>>> I'd suggest we just need something in docs/specs/firmware-metadata.rst
>>> for QEMU source tree.
>>>
>>> Potentially QEMU could even use the metadata files itself for finding
>>> the default firmeware images, instead of compiling this info into its
>>> binaries. I wouldn't suggest we need todo that right away, but bear it
>>> in mind as a potential use case.
>>
>> With qemu using this itself in mind it probably makes sense to specify
>> this as qapi schema.  That'll simplify parsing and using these files in
>> qemu, and possibly simplifies things on the libvirt side too.
> 
> I was thinking of an 'ini' style format, similar to that used by systemd
> unit files, but a JSON format file is a nicer fit with QEMU & Libvirt if
> we describe it with qapi.

I've created an RFC-level "qapi/firmware.json" schema file, based on
this discussion. It "builds", and the generated documentation looks
acceptable, superficially speaking.

Before I post "qapi/firmware.json" for getting comments, I'd like to
write JSON text that (a) describes firmware that I use, and (b) conforms
to the schema. IOW, I'd like to validate whether the schema is good
enough for describing at least such firmware that I know.

Is there a tool that generates example JSON objects from a given schema?
I vaguely recall there used to be one. Otherwise, writing the examples
manually looks arduous (and I wouldn't know how to verify them against
the schema).

Thanks!
Laszlo

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

[libvirt] [PATCH 4/4] qemu: Obtain reference on monConfig

[John Ferlan]

Because we allow a QEMU_JOB_DESTROY to occur while we're starting
up and we drop the @vm lock prior to qemuMonitorOpen, it's possible
that a domain destroy operation "wins" the race, calls qemuProcessStop
which will free and reinitialize priv->monConfig. Depending on the
exact timing either qemuMonitorOpen will be passed a NULL @config
variable or it will be using free'd (and possibly reclaimed) memory
as the @config parameter - neither of which is good.

Resolve this by localizing the @monConfig, taking an extra reference,
and then once we get the @vm lock again removing our reference since
we are done with it.

Signed-off-by: John Ferlan 
---
 src/qemu/qemu_process.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index a8dab92dd6..988c6b1537 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -1776,6 +1776,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
virDomainObjPtr vm, int asyncJob,
 qemuDomainObjPrivatePtr priv = vm->privateData;
 qemuMonitorPtr mon = NULL;
 unsigned long long timeout = 0;
+virDomainChrSourceDefPtr monConfig;
 
 if (qemuSecuritySetDaemonSocketLabel(driver->securityManager, vm->def) < 
0) {
 VIR_ERROR(_("Failed to set security context for monitor for %s"),
@@ -1794,10 +1795,12 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
virDomainObjPtr vm, int asyncJob,
 virObjectRef(vm);
 
 ignore_value(virTimeMillisNow(>monStart));
+monConfig = priv->monConfig;
+virObjectRef(monConfig);
 virObjectUnlock(vm);
 
 mon = qemuMonitorOpen(vm,
-  priv->monConfig,
+  monConfig,
   priv->monJSON,
   timeout,
   ,
@@ -1813,6 +1816,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
virDomainObjPtr vm, int asyncJob,
 
 virObjectLock(vm);
 virObjectUnref(vm);
+virObjectUnref(monConfig);
 priv->monStart = 0;
 
 if (!virDomainObjIsActive(vm)) {
-- 
2.13.6

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

[libvirt] [PATCH 0/4] Fix a race to using monConfig

[John Ferlan]

As reported by Marc Hartmayer :

https://www.redhat.com/archives/libvir-list/2018-March/msg01156.html

there is a race to using the priv->monConfig between the Create
and destroy domain processing. The patches describe the steps taken
to resolve the issue.

John Ferlan (4):
  conf: Use virDomainChrSourceDefNew for vhostuser
  qemu: Use virDomainChrSourceDefNew for monConfig
  conf: Convert virDomainChrSourceDefNew to return object
  qemu: Obtain reference on monConfig

 src/conf/domain_conf.c   | 37 -
 src/conf/domain_conf.h   |  3 +++
 src/libvirt_private.syms |  1 +
 src/qemu/qemu_domain.c   |  2 +-
 src/qemu/qemu_process.c  |  8 ++--
 5 files changed, 43 insertions(+), 8 deletions(-)

-- 
2.13.6

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

[libvirt] [PATCH 3/4] conf: Convert virDomainChrSourceDefNew to return object

[John Ferlan]

Let's use object referencing to handle the ChrSourceDef. A subsequent
patch then can allow the monConfig to take an extra reference before
dropping the domain lock to then ensure nothing free's the memory that
needs to be used.

Signed-off-by: John Ferlan 
---
 src/conf/domain_conf.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index fd57364cd4..b4c5de8b33 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2260,8 +2260,10 @@ virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
 return 0;
 }
 
-void virDomainChrSourceDefFree(virDomainChrSourceDefPtr def)
+static void
+virDomainChrSourceDefDispose(void *obj)
 {
+virDomainChrSourceDefPtr def = obj;
 size_t i;
 
 if (!def)
@@ -2275,11 +2277,16 @@ void virDomainChrSourceDefFree(virDomainChrSourceDefPtr 
def)
 virSecurityDeviceLabelDefFree(def->seclabels[i]);
 VIR_FREE(def->seclabels);
 }
+}
 
 
-VIR_FREE(def);
+void
+virDomainChrSourceDefFree(virDomainChrSourceDefPtr def)
+{
+virObjectUnref(def);
 }
 
+
 /* virDomainChrSourceDefIsEqual:
  * @src: Source
  * @tgt: Target
@@ -12211,12 +12218,32 @@ 
virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def,
 }
 
 
+static virClassPtr virDomainChrSourceDefClass;
+
+static int
+virDomainChrSourceDefOnceInit(void)
+{
+virDomainChrSourceDefClass = virClassNew(virClassForObject(),
+ "virDomainChrSourceDef",
+ sizeof(virDomainChrSourceDef),
+ virDomainChrSourceDefDispose);
+if (!virDomainChrSourceDefClass)
+return -1;
+else
+return 0;
+}
+
+VIR_ONCE_GLOBAL_INIT(virDomainChrSourceDef);
+
 virDomainChrSourceDefPtr
 virDomainChrSourceDefNew(virDomainXMLOptionPtr xmlopt)
 {
 virDomainChrSourceDefPtr def = NULL;
 
-if (VIR_ALLOC(def) < 0)
+if (virDomainChrSourceDefInitialize() < 0)
+return NULL;
+
+if (!(def = virObjectNew(virDomainChrSourceDefClass)))
 return NULL;
 
 if (xmlopt && xmlopt->privateData.chrSourceNew &&
-- 
2.13.6

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

[libvirt] [PATCH 2/4] qemu: Use virDomainChrSourceDefNew for monConfig

[John Ferlan]

Rather than VIR_ALLOC, use the New function for allocation. We
already use the Free function anyway.

Signed-off-by: John Ferlan 
---
 src/conf/domain_conf.c   | 2 +-
 src/conf/domain_conf.h   | 3 +++
 src/libvirt_private.syms | 1 +
 src/qemu/qemu_domain.c   | 2 +-
 src/qemu/qemu_process.c  | 2 +-
 5 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index caf3f47c63..fd57364cd4 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -12211,7 +12211,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
def,
 }
 
 
-static virDomainChrSourceDefPtr
+virDomainChrSourceDefPtr
 virDomainChrSourceDefNew(virDomainXMLOptionPtr xmlopt)
 {
 virDomainChrSourceDefPtr def = NULL;
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 68473c309e..89a7131fdb 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2827,6 +2827,9 @@ bool virDomainDefHasDeviceAddress(virDomainDefPtr def,
 
 void virDomainDefFree(virDomainDefPtr vm);
 
+virDomainChrSourceDefPtr
+virDomainChrSourceDefNew(virDomainXMLOptionPtr xmlopt);
+
 virDomainChrDefPtr virDomainChrDefNew(virDomainXMLOptionPtr xmlopt);
 
 virDomainDefPtr virDomainDefNew(void);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index c550310cc0..cab324c4d7 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -218,6 +218,7 @@ virDomainChrSourceDefClear;
 virDomainChrSourceDefCopy;
 virDomainChrSourceDefFree;
 virDomainChrSourceDefGetPath;
+virDomainChrSourceDefNew;
 virDomainChrSpicevmcTypeFromString;
 virDomainChrSpicevmcTypeToString;
 virDomainChrTcpProtocolTypeFromString;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index f03aa03e8a..bdc6e58d6e 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2422,7 +2422,7 @@ qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt,
 xmlNodePtr node = NULL;
 virQEMUCapsPtr qemuCaps = NULL;
 
-if (VIR_ALLOC(priv->monConfig) < 0)
+if (!(priv->monConfig = virDomainChrSourceDefNew(NULL)))
 goto error;
 
 if (!(monitorpath =
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index c0105c8b84..a8dab92dd6 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5717,7 +5717,7 @@ qemuProcessPrepareDomain(virQEMUDriverPtr driver,
 goto cleanup;
 }
 
-if (VIR_ALLOC(priv->monConfig) < 0)
+if (!(priv->monConfig = virDomainChrSourceDefNew(NULL)))
 goto cleanup;
 
 VIR_DEBUG("Preparing monitor state");
-- 
2.13.6

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

[libvirt] [PATCH 1/4] conf: Use virDomainChrSourceDefNew for vhostuser

[John Ferlan]

Rather than using VIR_ALLOC, use the New API since we already
use the virDomainChrSourceDefFree function when done.

Signed-off-by: John Ferlan 
---
 src/conf/domain_conf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index aacd06a87a..caf3f47c63 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -11138,7 +11138,7 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt,
 goto error;
 }
 
-if (VIR_ALLOC(def->data.vhostuser) < 0)
+if (!(def->data.vhostuser = virDomainChrSourceDefNew(xmlopt)))
 goto error;
 
 def->data.vhostuser->type = VIR_DOMAIN_CHR_TYPE_UNIX;
-- 
2.13.6

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

Re: [libvirt] Race condition between qemuDomainCreate and qemuDomainDestroy

[John Ferlan]

On 04/03/2018 07:47 AM, Marc Hartmayer wrote:
> On Tue, Mar 20, 2018 at 11:25 AM +0100, Marc Hartmayer 
>  wrote:
>> Hi,
>>
>> there is a race condition between 'qemuDomainCreate' and
>> 'qemuDomainDestroy' causing a NULL pointer segmentation fault when
>> accessing priv->monConfig. The race condition can be easily reproduced
>> using gdb.
>>
>> (gdb) set non-stop on
>> # set breakpoint on line 'mon = qemuMonitorOpen(vm, …)'
>> (gdb) b qemu_process.c:1799
>> # Actually, this second breakpoint is optional but it’s good to see
>> where priv->monConfig is set to NULL
>> # set breakpoint on line priv->monConfig = NULL;
>> (gdb) b qemu_process.c:6589
>> (gdb) run
>> # continue all threads - just for the case we hit a breakpoint already
>> (gdb) c -a
>>
>> Now start a domain (that is using QEMU)
>>
>> $ virsh start domain
>>
>> The first breakpoint will be hit. Now run in a second shell
>>
>> $ virsh destroy domain
>>
>> The second breakpoint will be hit. Continue the thread where the second
>> breakpoint was hit (for this example this is thread 4)
>>
>> (gdb) thread apply 4 continue
>>
>> Now continue the thread where the first breakpoint was hit.
>>
>> => Segmentation fault because of a NULL pointer dereference at
>>config->value
>>
>> Since I'm not very familiar with that part of the code, I wanted to ask
>> for your advice.
>>
>> Thanks in advance.
>>
>> Beste Grüße / Kind regards
>>Marc Hartmayer
>>
>> IBM Deutschland Research & Development GmbH
>> Vorsitzende des Aufsichtsrats: Martina Koederitz
>> Geschäftsführung: Dirk Wittkopp
>> Sitz der Gesellschaft: Böblingen
>> Registergericht: Amtsgericht Stuttgart, HRB 243294
> 
> Any ideas?
> 

Seeing as no one else has an exact or authoritative answer...

qemuDomainCreate{XML|WithFlags} (and a few others) will call
qemuProcessBeginJob which calls qemuDomainObjBeginAsyncJob and
qemuDomainObjSetAsyncJobMask which IIUC allows QEMU_JOB_DESTROY
to be run.

The qemuDomainDestroyFlags calls qemuProcessBeginStopJob which calls
qemuDomainObjBeginJob (e.g. sync job) using QEMU_JOB_DESTROY, which
again IIUC is allowed to happen alongside the Async job because of the
mask setting.

In the code where you've broken during create, the @vm object lock is
dropped allowing destroy to obtain it. So with the perfect timing and
storm the window of opportunity does exist that the monConfig could be
free'd and thus priv->monConfig set to NULL before or during the create
processing uses it in qemuMonitorOpen.  If during the processing, then
obviously the config-> would "appear" to be valid, but it may not
actually be what was passed.

The fix I believe involves using objects for virDomainChrSourceDef
rather than VIR_ALLOC'd and VIR_FREE'd memory directly. I've put
together a few patches and will post them shortly. Using the patches I
don't see a core, but rather the (I believe) expected "error: internal
error: qemu unexpectedly closed the monitor"

John



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

Re: [libvirt] [dbus PATCH 9/9] Implement Setter for Autostart property of Network Interface.

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:34PM +0200, Katerina Koukiou wrote:

In $subject remove the period.

> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Network.xml |  5 +++--
>  src/network.c| 22 +-
>  test/test_network.py |  8 
>  3 files changed, 32 insertions(+), 3 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 06/10] guests: Move $PATH configuration to shell profile

[Andrea Bolognani]

On Fri, 2018-04-06 at 17:03 +0200, Pavel Hrdina wrote:
> On Thu, Apr 05, 2018 at 02:22:16PM +0200, Andrea Bolognani wrote:
> > Same as for $MAKE, moving the configuration here makes it
> > easier to reproduce issues outside of the CI environment.
> > 
> > Signed-off-by: Andrea Bolognani 
> > ---
> >  guests/group_vars/all/main.yml | 6 --
> >  guests/templates/bashrc| 2 ++
> >  jobs/defaults.yaml | 1 -
> >  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> This should be probably moved after the following patch since it uses
> VIRT_PREFIX.

Good point. I'll swap them.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [dbus PATCH 5/9] Implement NetworkDefineXML method for Connect interface

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:30PM +0200, Katerina Koukiou wrote:
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Connect.xml |  6 ++
>  src/connect.c| 29 +
>  test/test_connect.py | 12 
>  3 files changed, 47 insertions(+)
> 
> diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
> index 5f5c5fe..e36b7f6 100644
> --- a/data/org.libvirt.Connect.xml
> +++ b/data/org.libvirt.Connect.xml
> @@ -56,6 +56,12 @@
>
>
>  
> +
> +   +value="See 
> https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkDefineXML"/>
> +  
> +  
> +
>  
>  value="See 
> https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkLookupByName"/>
> diff --git a/src/connect.c b/src/connect.c
> index 759b9fb..3a0e969 100644
> --- a/src/connect.c
> +++ b/src/connect.c
> @@ -358,6 +358,34 @@ virtDBusConnectNetworkCreateXML(GVariant *inArgs,
>  *outArgs = g_variant_new("(o)", path);
>  }
>  
> +static void
> +virtDBusConnectNetworkDefineXML(GVariant *inArgs,
> +GUnixFDList *inFDs G_GNUC_UNUSED,
> +const gchar *objectPath G_GNUC_UNUSED,
> +gpointer userData,
> +GVariant **outArgs,
> +GUnixFDList **outFDs G_GNUC_UNUSED,
> +GError **error)
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virNetwork) network = NULL;
> +g_autofree gchar *path = NULL;
> +gchar *xml;

const gchar *xml;

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [dbus PATCH 8/9] Implement Persistent property for Network Interface.

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:33PM +0200, Katerina Koukiou wrote:

In $subject remove the period.

> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Network.xml |  4 
>  src/network.c| 22 ++
>  test/test_network.py |  1 +
>  3 files changed, 27 insertions(+)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [dbus PATCH 7/9] Implement Active property for Network Interface.

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:32PM +0200, Katerina Koukiou wrote:

In $subject remove the period.

> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Network.xml |  4 
>  src/network.c| 22 ++
>  test/test_network.py |  1 +
>  3 files changed, 27 insertions(+)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [dbus PATCH 6/9] Implement GetXMLDesc method for Network Interface.

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:31PM +0200, Katerina Koukiou wrote:

In $subject remove the period.

> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Network.xml |  6 ++
>  src/network.c| 28 
>  test/test_network.py |  5 +
>  3 files changed, 39 insertions(+)

Reviewed-by: Pavel Hrdina 


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

[libvirt] [jenkins-ci PATCH 12/10] guests: Enable bash completion by default

[Andrea Bolognani]

In order for bash completion to be available right after login
we need to make sure the corresponding package is installed and,
for FreeBSD only, the enviroment script gets sourced.

Signed-off-by: Andrea Bolognani 
---
 guests/templates/bashrc  | 5 +
 guests/vars/projects/base.yml| 1 +
 guests/vars/projects/libvirt.yml | 1 -
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/guests/templates/bashrc b/guests/templates/bashrc
index 639a961..e925cd9 100644
--- a/guests/templates/bashrc
+++ b/guests/templates/bashrc
@@ -14,3 +14,8 @@ export PYTHONPATH="{{ PYTHONPATH }}"
 which python3 >/dev/null 2>&1 && export PYTHON="python3" || export 
PYTHON="python2"
 which gmake >/dev/null 2>&1 && export MAKE="gmake" || export MAKE="make"
 which ccache >/dev/null 2>&1 && export CC="ccache cc"
+
+# Enable bash completion. Only needed on FreeBSD, the system-wide
+# shell profile will take care of it for us everywhere else
+bash_completion=/usr/local/share/bash-completion/bash_completion.sh
+test -f "$bash_completion" && . "$bash_completion"
diff --git a/guests/vars/projects/base.yml b/guests/vars/projects/base.yml
index a0483d8..49d4d2e 100644
--- a/guests/vars/projects/base.yml
+++ b/guests/vars/projects/base.yml
@@ -4,6 +4,7 @@ packages:
   - automake
   - autopoint
   - bash
+  - bash-completion
   - ccache
   - chrony
   - cppi
diff --git a/guests/vars/projects/libvirt.yml b/guests/vars/projects/libvirt.yml
index 9f027f8..598dfc4 100644
--- a/guests/vars/projects/libvirt.yml
+++ b/guests/vars/projects/libvirt.yml
@@ -3,7 +3,6 @@ packages:
   - apparmor
   - augeas
   - avahi
-  - bash-completion
   - cyrus-sasl
   - device-mapper
   - dnsmasq
-- 
2.14.3

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

Re: [libvirt] [dbus PATCH 4/9] Implement NetworkCreateXML method for Connect interface

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:29PM +0200, Katerina Koukiou wrote:
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Connect.xml |  6 ++
>  src/connect.c| 29 +
>  test/test_connect.py | 26 ++
>  3 files changed, 61 insertions(+)
> 
> diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
> index 715aeef..5f5c5fe 100644
> --- a/data/org.libvirt.Connect.xml
> +++ b/data/org.libvirt.Connect.xml
> @@ -50,6 +50,12 @@
>
>
>  
> +
> +   +value="See 
> https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkCreateXML"/>
> +  
> +  
> +
>  
>  value="See 
> https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkLookupByName"/>
> diff --git a/src/connect.c b/src/connect.c
> index 9931c8f..759b9fb 100644
> --- a/src/connect.c
> +++ b/src/connect.c
> @@ -330,6 +330,34 @@ virtDBusConnectListNetworks(GVariant *inArgs,
>  *outArgs = g_variant_new_tuple(, 1);
>  }
>  
> +static void
> +virtDBusConnectNetworkCreateXML(GVariant *inArgs,
> +GUnixFDList *inFDs G_GNUC_UNUSED,
> +const gchar *objectPath G_GNUC_UNUSED,
> +gpointer userData,
> +GVariant **outArgs,
> +GUnixFDList **outFDs G_GNUC_UNUSED,
> +GError **error)
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virNetwork) network = NULL;
> +g_autofree gchar *path = NULL;
> +gchar *xml;

This can be const gchar *xml.

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [dbus PATCH 3/9] Add Domain prefix to DefineXML method, tests and related functions.

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:28PM +0200, Katerina Koukiou wrote:

Same comment for the $subject as in the previous patch.

> This method is domain specific and should be clear from the naming,
> so that we can later define *DefineXML methods for other entities.
> 
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Connect.xml |  2 +-
>  src/connect.c| 16 
>  test/test_connect.py |  4 ++--
>  3 files changed, 11 insertions(+), 11 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [dbus PATCH 2/9] Add Domain prefix to CreateXML method, test and related functions.

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:27PM +0200, Katerina Koukiou wrote:

In the $subject

s/, test and related functions.//

we don't end the subject with period and the part after comma can be
removed.

> This method is domain specific and should be clear from the naming,
> so that we can later define *CreateXML methods for other entities.
> 
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Connect.xml |  2 +-
>  src/connect.c| 16 
>  test/test_connect.py |  4 ++--
>  3 files changed, 11 insertions(+), 11 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [dbus PATCH 1/9] tests: Rename minimal_xml to minimal_domain_xml

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:20:26PM +0200, Katerina Koukiou wrote:
> Needed so as to keep consistent naming when we 'll introduce XML

s/we 'll/we'll/

> for other entities.
> 
> Signed-off-by: Katerina Koukiou 
> ---
>  test/test_connect.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 11/10] guests: Move $OSINFO_SYSTEM_DIR configuration to shell profile

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 01:40:18PM +0200, Andrea Bolognani wrote:
> This belongs with all the other enviroment settings, but it was
> somehow missed the first time around.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/group_vars/all/main.yml | 1 +
>  guests/templates/bashrc| 1 +
>  projects/libosinfo.yaml| 2 --
>  3 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 10/10] guests: Remove per-host make variable

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:20PM +0200, Andrea Bolognani wrote:
> We are figuring out which make binary we should use dynamically
> in the shell profile now, so this variable is redundant; plus,
> we were not actually using it anywhere.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/group_vars/all/main.yml| 1 -
>  guests/host_vars/libvirt-freebsd-10/main.yml  | 1 -
>  guests/host_vars/libvirt-freebsd-11/main.yml  | 1 -
>  guests/host_vars/libvirt-freebsd-current/main.yml | 1 -
>  4 files changed, 4 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 09/10] guests: Add Python configuration to shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:19PM +0200, Andrea Bolognani wrote:
> This is conceptually identical to how Perl is handled, except
> that we still need to override $PYTHONPATH in Jenkins jobs in
> order to be able to build projects using both Python 3 and
> Python 2 on the same guest. We might want to reconsider that
> decision, but for the time being this change is still helpful
> to people running guests outside of the CI environment.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/group_vars/all/main.yml| 1 +
>  guests/host_vars/libvirt-centos-6/main.yml| 1 +
>  guests/host_vars/libvirt-centos-7/main.yml| 1 +
>  guests/host_vars/libvirt-debian-8/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-26/main.yml   | 1 +
>  guests/host_vars/libvirt-fedora-27/main.yml   | 1 +
>  guests/host_vars/libvirt-fedora-rawhide/main.yml  | 1 +
>  guests/host_vars/libvirt-freebsd-10/main.yml  | 1 +
>  guests/host_vars/libvirt-freebsd-11/main.yml  | 1 +
>  guests/host_vars/libvirt-freebsd-current/main.yml | 1 +
>  guests/host_vars/libvirt-ubuntu-14/main.yml   | 1 +
>  guests/host_vars/libvirt-ubuntu-16/main.yml   | 1 +
>  guests/templates/bashrc   | 2 ++
>  15 files changed, 16 insertions(+)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 06/10] guests: Move $PATH configuration to shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:16PM +0200, Andrea Bolognani wrote:
> Same as for $MAKE, moving the configuration here makes it
> easier to reproduce issues outside of the CI environment.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/group_vars/all/main.yml | 6 --
>  guests/templates/bashrc| 2 ++
>  jobs/defaults.yaml | 1 -
>  3 files changed, 6 insertions(+), 3 deletions(-)

This should be probably moved after the following patch since it uses
VIRT_PREFIX.

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 08/10] guests: Move Perl configuration to shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:18PM +0200, Andrea Bolognani wrote:
> Same as for $VIRT_PREFIX and friends, we want these to be
> tracked along with the rest of the CI setup instead of being a
> completely opaque, side-loaded blob.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/group_vars/all/main.yml| 1 +
>  guests/host_vars/libvirt-centos-6/main.yml| 2 ++
>  guests/host_vars/libvirt-centos-7/main.yml| 2 ++
>  guests/host_vars/libvirt-debian-8/main.yml| 2 ++
>  guests/host_vars/libvirt-debian-9/main.yml| 2 ++
>  guests/host_vars/libvirt-debian-sid/main.yml  | 2 ++
>  guests/host_vars/libvirt-fedora-26/main.yml   | 2 ++
>  guests/host_vars/libvirt-fedora-27/main.yml   | 2 ++
>  guests/host_vars/libvirt-fedora-rawhide/main.yml  | 2 ++
>  guests/host_vars/libvirt-freebsd-10/main.yml  | 2 ++
>  guests/host_vars/libvirt-freebsd-11/main.yml  | 2 ++
>  guests/host_vars/libvirt-freebsd-current/main.yml | 2 ++
>  guests/host_vars/libvirt-ubuntu-14/main.yml   | 2 ++
>  guests/host_vars/libvirt-ubuntu-16/main.yml   | 2 ++
>  guests/templates/bashrc   | 1 +
>  15 files changed, 28 insertions(+)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 07/10] guests: Add more enviroment variables to shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:17PM +0200, Andrea Bolognani wrote:
> All these are currently defined per-worker at the Jenkins level,
> which has several disadvantages: first of all, they are completely
> invisible to anyone except people with admin access to the Jenkins
> instance; moreover, updating them requires a lot of clicking in
> the web interface, and change history is not tracked. Moving their
> configuration to the shell profile solves all those issues.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/group_vars/all/main.yml | 6 ++
>  guests/templates/bashrc| 6 ++
>  2 files changed, 12 insertions(+)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 03/10] guests: Add custom shell profile

[Pavel Hrdina]

On Fri, Apr 06, 2018 at 04:39:44PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-04-06 at 15:10 +0200, Andrea Bolognani wrote:
> > > I think that we should also load the system profile /etc/profile .. in
> > > case of 'jenkins' flavor we don't actually need it since that is used in
> > > automated tests but in case of 'test' flavor when developer will
> > > manually login into the guests might miss some features configured by
> > > thy system profile.
> > 
> > What kind of features are you thinking about, exactly?
> > 
> > /etc/profile can vary significantly between Linux versions, and on
> > FreeBSD it's not even loaded when using bash as the login shell
> > IIUC; however, in all cases the resulting environment is generally
> > pretty sane, so adding our own custom settings on top through the
> > user's profile works nicely.
> > 
> > Moreover, overriding setting in the user's profile instead of
> > tweaking them globally is a better approach in general IMHO, so if
> > there are specific features you'd like to address I would still
> > rather deal with them in the user's profile if at all possible.
> 
> Okay, so it looks like I misunderstood your comment: you were
> advocating for sourcing /etc/profile in the user's shell profile.
> 
> bash will actually load that file regardless, and on all Linux
> distributions the result is that features such as bash completion
> will be available to the user right after login, even with our
> custom shell profile in place.
> 
> FreeBSD, of course, behaves a little differently ;) You have to
> source the bash_completion script manually if you want that
> feature, as /etc/profile is tailored to the classic Bourne shell
> so it won't do that for you, and there is no such thing as a
> global bashrc that you can use.
> 
> All in all, it's pretty simple to add, but I think it's okay for
> it to be a follow-up patch. Are there more features you had in
> mind?

In that case and for FreeBSD there is no need to handle it.  I was
mostly concerned about Linux distributions.

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [PATCH 2/6] tpm: Add support for external swtpm TPM emulator

[Daniel P . Berrangé]

On Fri, Apr 06, 2018 at 10:49:23AM -0400, Stefan Berger wrote:
> On 04/06/2018 10:12 AM, Daniel P. Berrangé wrote:
> > On Fri, Apr 06, 2018 at 07:23:49AM -0400, Stefan Berger wrote:
> > > On 04/06/2018 04:26 AM, Daniel P. Berrangé wrote:
> > > > On Thu, Apr 05, 2018 at 05:56:02PM -0400, Stefan Berger wrote:
> > > > > This patch adds support for an external swtpm TPM emulator. The XML 
> > > > > for
> > > > > this type of TPM looks as follows:
> > > > > 
> > > > >
> > > > >  
> > > > >
> > 
> 
> > 
> > 
> > > > > +cmd = virCommandNew(swtpm_path);
> > > > > +if (!cmd)
> > > > > +goto error;
> > > > > +
> > > > > +virCommandClearCaps(cmd);
> > > > > +
> > > > > +virCommandAddArgList(cmd, "socket", "--daemon", "--ctrl", NULL);
> > > > > +virCommandAddArgFormat(cmd, "type=unixio,path=%s,mode=0600",
> > > > > +   tpm->data.emulator.source.data.nix.path);
> > > > > +
> > > > > +virCommandAddArg(cmd, "--tpmstate");
> > > > > +virCommandAddArgFormat(cmd, "dir=%s", storagepath);
> > > > > +
> > > > > +virCommandAddArg(cmd, "--log");
> > > > > +virCommandAddArgFormat(cmd, "file=%s", logfile);
> > > > > +
> > > > > +/* allow process to open logfile by root before dropping 
> > > > > privileges */
> > > > > +virCommandAllowCap(cmd, CAP_DAC_OVERRIDE);
> > > > Why can't we get have the log file be owned by the user that
> > > > swtpm runs as, instead of root ?
> > > I would have to look at this particular capability again. I initially 
> > > wanted
> > > to put the swtpm's log file also into /var/log/libvirt/qemu. It works nice
> > > of course when running swtpm as 'root' but not so much when running it as
> > > 'tss':
> > > 
> > > root@localhost tmp]$ sudo ls -l /var/log/libvirt/ | grep qemu
> > > drwx--. 2 root root 20480 Apr  5 16:14 qemu
> > Yeah the logs are owned by root these days, because they're not written by
> > qemu itself, instead virtlogd owns it.
> 
> [root@localhost log]# ls -lZ | grep libvirt
> drwx--. 6 root  root system_u:object_r:virt_log_t:s0
> 4096 Mar  1  2017 libvirt
> 
> Even /var/log/libvirt would not be accessible for the tss users.
> 
> > 
> > > So where do we put the swtpm's log files? /var/log/libvirt/swtpm?
> > Yeah, probably best to have a separate directory
> 
> It would have to be /var/log/swtpm unless we change the permissions on
> /var/log/libvirt ... ?

/var/log/swtpm is reasonable imho

> > > > I would feel better if we just directly killed the process - with
> > > > this approach if something goes wrong with swtpm it may never
> > > > respond to this request and stay running.
> > > swtpm can write a pidfile. I am only adding this later in this series.
> > > Problem is with --daemon libvirt doesn't know the pid of the swtpm 
> > > anymore.
> > The other option is to not use --daemon, and let libvirt write the pid
> > file, but that introduces the race with socket path creation again
> > which is not good.
> 
> Sounds like we should leave this as it is? Unless swtpm was broken, there
> shouldn't be a reason why the we wouldn't be able to shut down swtpm by
> sending a command to it. The socket and its directory must not have
> disappeared of course.

Agreed.

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/6] tpm: Add support for external swtpm TPM emulator

[Stefan Berger]

On 04/06/2018 10:12 AM, Daniel P. Berrangé wrote:

On Fri, Apr 06, 2018 at 07:23:49AM -0400, Stefan Berger wrote:

On 04/06/2018 04:26 AM, Daniel P. Berrangé wrote:

On Thu, Apr 05, 2018 at 05:56:02PM -0400, Stefan Berger wrote:

This patch adds support for an external swtpm TPM emulator. The XML for
this type of TPM looks as follows:

   
 
   








+cmd = virCommandNew(swtpm_path);
+if (!cmd)
+goto error;
+
+virCommandClearCaps(cmd);
+
+virCommandAddArgList(cmd, "socket", "--daemon", "--ctrl", NULL);
+virCommandAddArgFormat(cmd, "type=unixio,path=%s,mode=0600",
+   tpm->data.emulator.source.data.nix.path);
+
+virCommandAddArg(cmd, "--tpmstate");
+virCommandAddArgFormat(cmd, "dir=%s", storagepath);
+
+virCommandAddArg(cmd, "--log");
+virCommandAddArgFormat(cmd, "file=%s", logfile);
+
+/* allow process to open logfile by root before dropping privileges */
+virCommandAllowCap(cmd, CAP_DAC_OVERRIDE);

Why can't we get have the log file be owned by the user that
swtpm runs as, instead of root ?

I would have to look at this particular capability again. I initially wanted
to put the swtpm's log file also into /var/log/libvirt/qemu. It works nice
of course when running swtpm as 'root' but not so much when running it as
'tss':

root@localhost tmp]$ sudo ls -l /var/log/libvirt/ | grep qemu
drwx--. 2 root root 20480 Apr  5 16:14 qemu

Yeah the logs are owned by root these days, because they're not written by
qemu itself, instead virtlogd owns it.


[root@localhost log]# ls -lZ | grep libvirt
drwx--. 6 root  root 
system_u:object_r:virt_log_t:s0   4096 Mar  1  2017 libvirt


Even /var/log/libvirt would not be accessible for the tss users.




So where do we put the swtpm's log files? /var/log/libvirt/swtpm?

Yeah, probably best to have a separate directory


It would have to be /var/log/swtpm unless we change the permissions on 
/var/log/libvirt ... ?



Iirc the CAP_DAC_OVERRIDE became necessary when swtpm tries to append to the
log that 'tss' owns but now libvirt runs it as 'root'. I think that was the
reason I added it. One way to solve this would be to chown() the files
before starting swtpm. Is that the solution?

I'd think a separate dir is best




+if (swtpm_user > 0) {
+virCommandAddArg(cmd, "--runas");
+virCommandAddArgFormat(cmd, "%u", swtpm_user);
+virCommandAllowCap(cmd, CAP_SETGID);
+virCommandAllowCap(cmd, CAP_SETUID);
+}

Then we could tell virCommand to set the UID/GID before it even
executes this, and not use -runas, thus avoiding the need to
allow theses capabilities.

And the directory it writes the logs in would have to have ownership of
either root:root or tss:root (or tss:tss), depending on how libvirt is
currently configured? Again chown() the dir before starting?




+/*
+ * virTPMStopEmulator
+ * @tpm: TPM definition
+ * @vmuuid: the UUID of the VM
+ * @verbose: whether to report errors
+ *
+ * Gracefully stop the swptm
+ */
+void
+virTPMStopEmulator(virDomainTPMDefPtr tpm, const unsigned char *vmuuid,
+   bool verbose)
+{
+virCommandPtr cmd;
+int exitstatus;
+char *pathname;
+char *errbuf = NULL;
+
+(void)vmuuid;
+if (virTPMEmulatorInit() < 0)
+return;
+
+if (!(pathname = virTPMCreateEmulatorSocket(vmuuid)))
+return;
+
+cmd = virCommandNew(swtpm_ioctl);
+if (!cmd) {
+VIR_FREE(pathname);
+return;
+}
+
+virCommandAddArgList(cmd, "--unix", pathname, "-s", NULL);
+
+virCommandSetErrorBuffer(cmd, );
+
+if (virCommandRun(cmd, ) < 0 || exitstatus != 0) {
+if (verbose)
+VIR_ERROR(_("Could not run swtpm_ioctl -s '%s'."
+  " existstatus: %d\nstderr: %s"),
+  swtpm_ioctl, exitstatus, errbuf);
+}
+
+virCommandFree(cmd);

I would feel better if we just directly killed the process - with
this approach if something goes wrong with swtpm it may never
respond to this request and stay running.

swtpm can write a pidfile. I am only adding this later in this series.
Problem is with --daemon libvirt doesn't know the pid of the swtpm anymore.

The other option is to not use --daemon, and let libvirt write the pid
file, but that introduces the race with socket path creation again
which is not good.


Sounds like we should leave this as it is? Unless swtpm was broken, 
there shouldn't be a reason why the we wouldn't be able to shut down 
swtpm by sending a command to it. The socket and its directory must not 
have disappeared of course.


  Stefan




Regards,
Daniel



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

Re: [libvirt] [jenkins-ci PATCH 03/10] guests: Add custom shell profile

[Andrea Bolognani]

On Fri, 2018-04-06 at 15:10 +0200, Andrea Bolognani wrote:
> > I think that we should also load the system profile /etc/profile .. in
> > case of 'jenkins' flavor we don't actually need it since that is used in
> > automated tests but in case of 'test' flavor when developer will
> > manually login into the guests might miss some features configured by
> > thy system profile.
> 
> What kind of features are you thinking about, exactly?
> 
> /etc/profile can vary significantly between Linux versions, and on
> FreeBSD it's not even loaded when using bash as the login shell
> IIUC; however, in all cases the resulting environment is generally
> pretty sane, so adding our own custom settings on top through the
> user's profile works nicely.
> 
> Moreover, overriding setting in the user's profile instead of
> tweaking them globally is a better approach in general IMHO, so if
> there are specific features you'd like to address I would still
> rather deal with them in the user's profile if at all possible.

Okay, so it looks like I misunderstood your comment: you were
advocating for sourcing /etc/profile in the user's shell profile.

bash will actually load that file regardless, and on all Linux
distributions the result is that features such as bash completion
will be available to the user right after login, even with our
custom shell profile in place.

FreeBSD, of course, behaves a little differently ;) You have to
source the bash_completion script manually if you want that
feature, as /etc/profile is tailored to the classic Bourne shell
so it won't do that for you, and there is no such thing as a
global bashrc that you can use.

All in all, it's pretty simple to add, but I think it's okay for
it to be a follow-up patch. Are there more features you had in
mind?

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [PATCH 2/6] tpm: Add support for external swtpm TPM emulator

[Daniel P . Berrangé]

On Fri, Apr 06, 2018 at 07:23:49AM -0400, Stefan Berger wrote:
> On 04/06/2018 04:26 AM, Daniel P. Berrangé wrote:
> > On Thu, Apr 05, 2018 at 05:56:02PM -0400, Stefan Berger wrote:
> > > This patch adds support for an external swtpm TPM emulator. The XML for
> > > this type of TPM looks as follows:
> > > 
> > >   
> > > 
> > >   


> > > +if (virCommandRun(cmd, ) < 0 || exitstatus != 0) {
> > > +VIR_ERROR("Could not start 'swtpm'. exitstatus: %d\n"
> > > +  "stderr: %s\n", exitstatus, errbuf);
> > > +virReportError(VIR_ERR_INTERNAL_ERROR,
> > > +   _("Could not start 'swtpm'. exitstatus: %d, "
> > > +   "error: %s"), exitstatus, errbuf);
> > > +goto error;
> > > +}
> > > +
> > > +/* sync the startup of the swtpm's Unix socket with the start of 
> > > QEMU */
> > > +if (virTPMTryConnect(tpm->data.emulator.source.data.nix.path,
> > > + 3 * 1000 * 1000) < 0) {
> > > +virReportError(VIR_ERR_INTERNAL_ERROR,
> > > +   _("Could not connect to the swtpm on '%s'"),
> > > +   tpm->data.emulator.source.data.nix.path);
> > > +goto error;
> > > +}
> > Ewww, this is really not nice to deal with startup races.
> > 
> > You're using the --daemon flag to swtpm, so swtpm should make sure
> > that it doesn't daemonize itself & let the parent exit, until the
> > UNIX socket is actually ready to access connections. Can we just
> > get swtpm fixed in this way.
> 
> It does that actually already and the socket file is there once it
> daemonizes itself.

If that's the case, why do you need this TryConnect busy waiting loop
at all ? It should be immediately available.


> > > +cmd = virCommandNew(swtpm_path);
> > > +if (!cmd)
> > > +goto error;
> > > +
> > > +virCommandClearCaps(cmd);
> > > +
> > > +virCommandAddArgList(cmd, "socket", "--daemon", "--ctrl", NULL);
> > > +virCommandAddArgFormat(cmd, "type=unixio,path=%s,mode=0600",
> > > +   tpm->data.emulator.source.data.nix.path);
> > > +
> > > +virCommandAddArg(cmd, "--tpmstate");
> > > +virCommandAddArgFormat(cmd, "dir=%s", storagepath);
> > > +
> > > +virCommandAddArg(cmd, "--log");
> > > +virCommandAddArgFormat(cmd, "file=%s", logfile);
> > > +
> > > +/* allow process to open logfile by root before dropping privileges 
> > > */
> > > +virCommandAllowCap(cmd, CAP_DAC_OVERRIDE);
> > Why can't we get have the log file be owned by the user that
> > swtpm runs as, instead of root ?
> 
> I would have to look at this particular capability again. I initially wanted
> to put the swtpm's log file also into /var/log/libvirt/qemu. It works nice
> of course when running swtpm as 'root' but not so much when running it as
> 'tss':
> 
> root@localhost tmp]$ sudo ls -l /var/log/libvirt/ | grep qemu
> drwx--. 2 root root 20480 Apr  5 16:14 qemu

Yeah the logs are owned by root these days, because they're not written by
qemu itself, instead virtlogd owns it.

> So where do we put the swtpm's log files? /var/log/libvirt/swtpm?

Yeah, probably best to have a separate directory

> Iirc the CAP_DAC_OVERRIDE became necessary when swtpm tries to append to the
> log that 'tss' owns but now libvirt runs it as 'root'. I think that was the
> reason I added it. One way to solve this would be to chown() the files
> before starting swtpm. Is that the solution?

I'd think a separate dir is best

> 
> 
> > 
> > > +if (swtpm_user > 0) {
> > > +virCommandAddArg(cmd, "--runas");
> > > +virCommandAddArgFormat(cmd, "%u", swtpm_user);
> > > +virCommandAllowCap(cmd, CAP_SETGID);
> > > +virCommandAllowCap(cmd, CAP_SETUID);
> > > +}
> > Then we could tell virCommand to set the UID/GID before it even
> > executes this, and not use -runas, thus avoiding the need to
> > allow theses capabilities.
> 
> And the directory it writes the logs in would have to have ownership of
> either root:root or tss:root (or tss:tss), depending on how libvirt is
> currently configured? Again chown() the dir before starting?
> 
> > 
> > 
> > > +/*
> > > + * virTPMStopEmulator
> > > + * @tpm: TPM definition
> > > + * @vmuuid: the UUID of the VM
> > > + * @verbose: whether to report errors
> > > + *
> > > + * Gracefully stop the swptm
> > > + */
> > > +void
> > > +virTPMStopEmulator(virDomainTPMDefPtr tpm, const unsigned char *vmuuid,
> > > +   bool verbose)
> > > +{
> > > +virCommandPtr cmd;
> > > +int exitstatus;
> > > +char *pathname;
> > > +char *errbuf = NULL;
> > > +
> > > +(void)vmuuid;
> > > +if (virTPMEmulatorInit() < 0)
> > > +return;
> > > +
> > > +if (!(pathname = virTPMCreateEmulatorSocket(vmuuid)))
> > > +return;
> > > +
> > > +cmd = virCommandNew(swtpm_ioctl);
> > > +if (!cmd) {
> > > +VIR_FREE(pathname);
> > > +return;
> > > +}
> > > +
> > > 

Re: [libvirt] [PATCH 2/6] tpm: Add support for external swtpm TPM emulator

[Stefan Berger]

On 04/06/2018 07:23 AM, Stefan Berger wrote:

On 04/06/2018 04:26 AM, Daniel P. Berrangé wrote:

On Thu, Apr 05, 2018 at 05:56:02PM -0400, Stefan Berger wrote:

This patch adds support for an external swtpm TPM emulator. The XML for
this type of TPM looks as follows:

  

  

The XML will currently only start a TPM 1.2.

Upon the first start, libvirt will run `swtpm_setup`, which will 
simulate the
manufacturing of a TPM and create certificates for it and write them 
into the

NVRAM location of the emulated TPM.

Then, libvirt will automatically start the swtpm TPM emulator using 
the `swtpm`

executable.

Once the VM terminates, libvirt uses the swtpm_ioctl executable to 
gracefully
shut down the `swtpm` in case it is still running (QEMU did not send 
shutdown)

or clean up the socket file.

The above mentioned executables must be found in the PATH.

The executables can either be run as root or started as root and 
switch to
the tss user. The requirement for the tss user comes through 'tcsd', 
which
is used for the simulation of the manufacturing. Which user is used 
can be

configured through qemu.conf.

The swtpm writes out state into files. The state is kept in 
/var/lib/libvirt/tpm:


[root@localhost libvirt]# ls -lZ | grep tpm

drwx--x--x. 7 root root unconfined_u:object_r:virt_var_lib_t:s0 4096 
Apr  5 16:22 tpm


The directory /var/lib/libvirt/tpm maintains per-TPM state 
directories but
also hosts the UnixIO socket of running swtpms, which QEMU uses for 
communicating
with them. At this point only the socket file is labeled properly 
and made accessible

for QEMU, which runs under the qemu user:

/var/lib is for persistent state while /var/run is for transient
state, so I think sockets should be under /var/run instead.


/var/run/libvirt/qemu then ?


I now moved it into this neighborhood, which seems good due to the 
existing permissions:


# ls -lZ domain-1-testvm/
total 4
-rw---. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c40,c612 32 
Apr  6 09:55 master-key.aes
srwxrwxr-x. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c40,c612 0 
Apr  6 09:55 monitor.sock
srw---. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c40,c612 0 
Apr  6 09:55 swtpm.sock


Stefan

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

Re: [libvirt] [jenkins-ci PATCH 0/3] Drop CentOS 6, which makes some nice cleanups possible

[Andrea Bolognani]

On Fri, 2018-04-06 at 14:43 +0100, Daniel P. Berrangé wrote:
> > > It just occurred to me that libvirt.org is running on CentOS 6, and we
> > > rely on being able to run  configure, make & make dist there, so that
> > > we can do things like publish the website, create nightly snapshots,
> > > etc. So even if we don't support /running/ libvirt on CentOS 6, we'll
> > > need to make sure we can at least do minimal builds - doesn't need
> > > hypervisors enabled, as long as make dist still works.  So I think it
> > > is probably worth keeping at least the core libvirt build on CentOS 6
> > > CI, even if we turn off the sub-project like language bindings.
> > 
> > Alternatively, we can upgrade libvirt.org to centos 7.
> 
> Not something I would do myself - would have to be DV who decides to
> do that.

Seems to me like that's the way to go. I don't think we want to have
any ifs or buts in our support matrix: it should be very clear-cut
in order to preserve our sanity, and also to ensure people looking
at the project from outside don't get confused by mixed signals.

If DV doesn't have time to take care of upgrading but also doesn't
have a problem with the idea, I wouldn't mind looking into it myself.

-- 
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 0/3] Drop CentOS 6, which makes some nice cleanups possible

[Daniel P . Berrangé]

On Fri, Apr 06, 2018 at 03:38:34PM +0200, Michal Privoznik wrote:
> On 04/06/2018 03:20 PM, Daniel P. Berrangé wrote:
> > On Fri, Apr 06, 2018 at 01:58:07PM +0200, Andrea Bolognani wrote:
> >> This applies on top of
> >>
> >>   https://www.redhat.com/archives/libvir-list/2018-April/msg00410.html
> >>
> >> and, of course, should only be pushed after
> >>
> >>   https://www.redhat.com/archives/libvir-list/2018-April/msg00326.html
> >>
> >> or a follow-up version has been pushed.
> > 
> > It just occurred to me that libvirt.org is running on CentOS 6, and we
> > rely on being able to run  configure, make & make dist there, so that
> > we can do things like publish the website, create nightly snapshots,
> > etc. So even if we don't support /running/ libvirt on CentOS 6, we'll
> > need to make sure we can at least do minimal builds - doesn't need
> > hypervisors enabled, as long as make dist still works.  So I think it
> > is probably worth keeping at least the core libvirt build on CentOS 6
> > CI, even if we turn off the sub-project like language bindings.
> > 
> 
> Alternatively, we can upgrade libvirt.org to centos 7.

Not something I would do myself - would have to be DV who decides to
do that.

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] [jenkins-ci PATCH 0/3] Drop CentOS 6, which makes some nice cleanups possible

[Michal Privoznik]

On 04/06/2018 03:20 PM, Daniel P. Berrangé wrote:
> On Fri, Apr 06, 2018 at 01:58:07PM +0200, Andrea Bolognani wrote:
>> This applies on top of
>>
>>   https://www.redhat.com/archives/libvir-list/2018-April/msg00410.html
>>
>> and, of course, should only be pushed after
>>
>>   https://www.redhat.com/archives/libvir-list/2018-April/msg00326.html
>>
>> or a follow-up version has been pushed.
> 
> It just occurred to me that libvirt.org is running on CentOS 6, and we
> rely on being able to run  configure, make & make dist there, so that
> we can do things like publish the website, create nightly snapshots,
> etc. So even if we don't support /running/ libvirt on CentOS 6, we'll
> need to make sure we can at least do minimal builds - doesn't need
> hypervisors enabled, as long as make dist still works.  So I think it
> is probably worth keeping at least the core libvirt build on CentOS 6
> CI, even if we turn off the sub-project like language bindings.
> 

Alternatively, we can upgrade libvirt.org to centos 7.

Michal

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

Re: [libvirt] [jenkins-ci PATCH 0/3] Drop CentOS 6, which makes some nice cleanups possible

[Daniel P . Berrangé]

On Fri, Apr 06, 2018 at 01:58:07PM +0200, Andrea Bolognani wrote:
> This applies on top of
> 
>   https://www.redhat.com/archives/libvir-list/2018-April/msg00410.html
> 
> and, of course, should only be pushed after
> 
>   https://www.redhat.com/archives/libvir-list/2018-April/msg00326.html
> 
> or a follow-up version has been pushed.

It just occurred to me that libvirt.org is running on CentOS 6, and we
rely on being able to run  configure, make & make dist there, so that
we can do things like publish the website, create nightly snapshots,
etc. So even if we don't support /running/ libvirt on CentOS 6, we'll
need to make sure we can at least do minimal builds - doesn't need
hypervisors enabled, as long as make dist still works.  So I think it
is probably worth keeping at least the core libvirt build on CentOS 6
CI, even if we turn off the sub-project like language bindings.


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] [jenkins-ci PATCH 05/10] guests: Move make configuration to shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:15PM +0200, Andrea Bolognani wrote:
> Now that we have our custom shell profile, we can pick the
> correct make variant dynamically there instead of doing it
> in the Jenkins job definition, so that the $MAKE variable
> will also be available when using the guests outside of the
> CI environment.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/templates/bashrc | 1 +
>  jobs/defaults.yaml  | 5 -
>  2 files changed, 1 insertion(+), 5 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [jenkins-ci PATCH 03/10] guests: Add custom shell profile

[Andrea Bolognani]

On Fri, 2018-04-06 at 14:58 +0200, Pavel Hrdina wrote:
> > diff --git a/guests/templates/bash_profile b/guests/templates/bash_profile
> > new file mode 100644
> > index 000..a82a60e
> > --- /dev/null
> > +++ b/guests/templates/bash_profile
> > @@ -0,0 +1 @@
> > +test -f ~/.bashrc && . ~/.bashrc
> > diff --git a/guests/templates/bashrc b/guests/templates/bashrc
> > new file mode 100644
> > index 000..6640da6
> > --- /dev/null
> > +++ b/guests/templates/bashrc
> > @@ -0,0 +1 @@
> > +export PS1="[\u@\h \w]\$ "
> 
> I think that we should also load the system profile /etc/profile .. in
> case of 'jenkins' flavor we don't actually need it since that is used in
> automated tests but in case of 'test' flavor when developer will
> manually login into the guests might miss some features configured by
> thy system profile.

What kind of features are you thinking about, exactly?

/etc/profile can vary significantly between Linux versions, and on
FreeBSD it's not even loaded when using bash as the login shell
IIUC; however, in all cases the resulting environment is generally
pretty sane, so adding our own custom settings on top through the
user's profile works nicely.

Moreover, overriding setting in the user's profile instead of
tweaking them globally is a better approach in general IMHO, so if
there are specific features you'd like to address I would still
rather deal with them in the user's profile if at all possible.

-- 
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 04/10] guests: Move ccache configuration to shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:14PM +0200, Andrea Bolognani wrote:
> Now that we have our custom shell profile, making sure ccache
> is used is way simpler.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/tasks/users.yml  | 18 --
>  guests/templates/bashrc |  2 ++
>  2 files changed, 2 insertions(+), 18 deletions(-)

Reviewed-by: Pavel Hrdina 


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

Re: [libvirt] [PATCH 00/68] qemu: Refactor migration parameters

[Jiri Denemark]

On Wed, Apr 04, 2018 at 16:40:49 +0200, Jiri Denemark wrote:
> This series changes the way we handle migration parameters and
> capabilities with several goals:
> 
> - make it all consistent and avoid storing the same parameters in
>   several structs
> - reduce the number of QMP commands we use for setting migration
>   capabilities
> - concentrate the logic in a separate file and make the code for
>   migration parameters and capabilities in qemu_migration.c less
>   complicated
> - reset all parameters and capabilities at the end of migration
> - make adding new parameters and capabilities easier
> 
> Jiri Denemark (68):
>   qemu: Move qemuDomainCheckMigrationCapabilities
>   qemu: Rename qemuMigrationAnyCapsGet as qemuMigrationCapsGet
>   qemu: Rename qemuMigrationParams
>   qemu: New file for all APIs related to migration parameters
>   qemu: Reindent qemuMigrationParamsSetEmptyTLS

I realized I forgot to do a few more changes on of which will affect
several commits up until here.

Thanks for the review so far, but you can ignore this series now and
continue with v2 once I finish it.

Jirka

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

Re: [libvirt] [PATCH 4/4] news: Update the news file with the log filter wildcard improvement

[Ján Tomko]

On Tue, Apr 03, 2018 at 10:45:49AM +0200, Erik Skultety wrote:

Signed-off-by: Erik Skultety 
---
docs/news.xml | 12 
1 file changed, 12 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 87f52e83e..6dab4844d 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -47,6 +47,18 @@
  supported. In fact, kernel has been supporting this since 4.10.

  
+  
+
+  logging: Introduce wildcard to log filters
+
+
+  In an effort to deprecate the log_level variable in favour of the log
+  filters, introduce a wildcard filter, e.g. '1:*'. This change is most
+  noticeable during runtime using virt-admin, where the only way to
+  mimic the log_level's functionality has been to specify a number of
+  filters which can a bit painful.


can be

ACK

Jano


+
+  



--
2.14.3

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


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

Re: [libvirt] [PATCH 3/4] util: virlog: Introduce wildcard to log filters

[Ján Tomko]

On Tue, Apr 03, 2018 at 10:45:48AM +0200, Erik Skultety wrote:

Since the introduction of log tuning capabilities to virt-admin by
@06b91785, this has been a much needed missing improvement on the way to
deprecate the global 'log_level'.

Signed-off-by: Erik Skultety 
---
src/remote/libvirtd.conf |  4 +++-
src/util/virlog.c| 44 +++-
src/util/virlog.h|  1 +
3 files changed, 47 insertions(+), 2 deletions(-)



ACK


diff --git a/src/remote/libvirtd.conf b/src/remote/libvirtd.conf
index 9c0080dc0..7d823cf1a 100644
--- a/src/remote/libvirtd.conf
+++ b/src/remote/libvirtd.conf
@@ -368,7 +368,9 @@
# Multiple filters can be defined in a single @filters, they just need to be
# separated by spaces. Note that libvirt performs "first" match, i.e. if
# there are concurrent filters, the first one that matches will be applied,
-# given the order in log_filters.
+# given the order in log_filters with the exception of a wildcard filter, since
+# that's only taken into account if no other filter has matched, so
+# "4:* 1:util.pci" and "1:util.pci 4:*" are equivalent definitions.
#


Also, "4:* 1:util.pci 1:*" is equivalent.


# e.g. to only get warning or errors from the remote layer and only errors
# from the event layer:


Jano


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

Re: [libvirt] [PATCH 1/4] virlog: Fix a typo in virLogParseFilter's error msg

[Ján Tomko]

On Tue, Apr 03, 2018 at 10:45:46AM +0200, Erik Skultety wrote:

This was some copy-paste leftover.

Signed-off-by: Erik Skultety 
---
src/util/virlog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)



ACK

Jano


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

Re: [libvirt] [PATCH 2/4] libvirtd.conf: Document that we do a 'first' match on log filters

[Ján Tomko]

On Tue, Apr 03, 2018 at 10:45:47AM +0200, Erik Skultety wrote:

When applying the log filters, one has to define the more specific
filters before the generic ones, because the first filter that matches
will be applied. However, we've been missing this information in the
config, so it always has been a trial-error scenario figuring out that
e.g. '4:util 1:util.pci' doesn't actually enable verbose logging on the
src/util/virpci.c module because 4:util will be matched first.

Signed-off-by: Erik Skultety 
---
src/remote/libvirtd.conf | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)



ACK

Jano


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

Re: [libvirt] [jenkins-ci PATCH 03/10] guests: Add custom shell profile

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:13PM +0200, Andrea Bolognani wrote:
> We want to take control of the user's environment. For now the
> custom shell profile only sets the prompt, but it will later
> be used to influence the build environment.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/tasks/users.yml| 17 +
>  guests/templates/bash_profile |  1 +
>  guests/templates/bashrc   |  1 +
>  3 files changed, 19 insertions(+)
>  create mode 100644 guests/templates/bash_profile
>  create mode 100644 guests/templates/bashrc
> 
> diff --git a/guests/tasks/users.yml b/guests/tasks/users.yml
> index 1ecacee..8e59fa9 100644
> --- a/guests/tasks/users.yml
> +++ b/guests/tasks/users.yml
> @@ -82,3 +82,20 @@
>  owner: '{{ flavor }}'
>  group: '{{ flavor }}'
>  create: yes
> +
> +- name: '{{ flavor }}: Create shell profile'
> +  template:
> +src: templates/{{ item }}
> +dest: /home/{{ flavor }}/.{{ item }}
> +owner: '{{ flavor }}'
> +group: '{{ flavor }}'
> +  with_items:
> +- bash_profile
> +- bashrc
> +
> +- name: '{{ flavor }}: Remove existing shell profile'
> +  file:
> +path: /home/{{ flavor }}/.{{ item }}
> +state: absent
> +  with_items:
> +- profile
> diff --git a/guests/templates/bash_profile b/guests/templates/bash_profile
> new file mode 100644
> index 000..a82a60e
> --- /dev/null
> +++ b/guests/templates/bash_profile
> @@ -0,0 +1 @@
> +test -f ~/.bashrc && . ~/.bashrc
> diff --git a/guests/templates/bashrc b/guests/templates/bashrc
> new file mode 100644
> index 000..6640da6
> --- /dev/null
> +++ b/guests/templates/bashrc
> @@ -0,0 +1 @@
> +export PS1="[\u@\h \w]\$ "

I think that we should also load the system profile /etc/profile .. in
case of 'jenkins' flavor we don't actually need it since that is used in
automated tests but in case of 'test' flavor when developer will
manually login into the guests might miss some features configured by
thy system profile.

Pavel


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

Re: [libvirt] [PATCH 1/4] conf: Fix error path logic in virDomainObjListAddLocked

[Michal Privoznik]

On 03/29/2018 02:34 PM, John Ferlan wrote:
> If the virHashAddEntry fails, then we need to "careful" about
> how we free the @vm. When virDomainObjNew returns there is one
> reference and the object is locked, so use virDomainObjEndAPI
> when done.
> 
> Add a virObjectRef in the error path for the second virHashAddEntry
> call since it doesn't call virObjectRef, but virHashRemoveEntry
> will call virObjectUnref because virObjectFreeHashData is called
> when the element is removed from the hash table as set up in
> virDomainObjListNew.
> 
> Eventually these paths should goto error and error should be changed
> to use EndAPI as well, but that requires more adjustments to other
> paths in the code to have a locked and ref counted @vm.
> 
> Signed-off-by: John Ferlan 
> ---
>  src/conf/virdomainobjlist.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c
> index 87a742b1e..2ae8a41a1 100644
> --- a/src/conf/virdomainobjlist.c
> +++ b/src/conf/virdomainobjlist.c
> @@ -296,12 +296,14 @@ virDomainObjListAddLocked(virDomainObjListPtr doms,
>  
>  virUUIDFormat(def->uuid, uuidstr);
>  if (virHashAddEntry(doms->objs, uuidstr, vm) < 0) {
> -virObjectUnref(vm);
> +virObjectEndAPI();

s/virObjectEndAPI/virDomainObjEndAPI/ here and down too ;-)

>  return NULL;
>  }
>  
>  if (virHashAddEntry(doms->objsName, def->name, vm) < 0) {
> +virObjectRef(vm);
>  virHashRemoveEntry(doms->objs, uuidstr);
> +virObjectEndAPI();
>  return NULL;
>  }
>  
> 

ACK

Michal

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

Re: [libvirt] [PATCH 3/4] conf: Introduce virDomainObjListAddObjLocked

[Michal Privoznik]

On 03/29/2018 02:34 PM, John Ferlan wrote:
> Create a common helper to add an object to the locked domain
> objlist hash tables and use it.
> 
> Signed-off-by: John Ferlan 
> ---
>  src/conf/virdomainobjlist.c | 64 
> +++--
>  1 file changed, 39 insertions(+), 25 deletions(-)
> 
> diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c
> index 765f46d5a..7022abe09 100644
> --- a/src/conf/virdomainobjlist.c
> +++ b/src/conf/virdomainobjlist.c
> @@ -220,6 +220,42 @@ virDomainObjPtr 
> virDomainObjListFindByName(virDomainObjListPtr doms,
>  }
>  
>  
> +/**
> + * @doms: Domain object list pointer
> + * @vm: Domain object to be added
> + *
> + * Upon entry @vm should have at least 1 ref and be locked.
> + *
> + * Add the @vm into the @doms->objs and @doms->objsName hash
> + * tables.
> + *
> + * Returns 0 on success with 2 references and locked
> + *-1 on failure with 1 reference and locked
> + */
> +static int
> +virDomainObjListAddObjLocked(virDomainObjListPtr doms,
> + virDomainObjPtr vm)
> +{
> +char uuidstr[VIR_UUID_STRING_BUFLEN];
> +
> +virUUIDFormat(vm->def->uuid, uuidstr);
> +if (virHashAddEntry(doms->objs, uuidstr, vm) < 0)
> +return -1;
> +
> +if (virHashAddEntry(doms->objsName, vm->def->name, vm) < 0) {
> +virObjectRef(vm);
> +virHashRemoveEntry(doms->objs, uuidstr);
> +return -1;
> +}
> +
> +/* Since domain is in two hash tables, increment the
> + * reference counter */
> +virObjectRef(vm);

I think this virObjectRef() could be moved in between those two
virHashAddEntry() calls and thus the later call to virObjectRef() can be
dropped then.

Michal

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

Re: [libvirt] [PATCH 0/4] Initial phase of domain obj add/remove cleanup

[Michal Privoznik]

On 03/29/2018 02:34 PM, John Ferlan wrote:
> As evidenced by various code comments, the process of adding and
> removing objects to/from the domain object list is problematic.
> 
> Long story short is that the Add logic doesn't generate enough
> object references and the Remove logic removes one extra than
> was added during Add and leaves the object unlocked upon return
> (as well as doing a small fire dance to ensure proper lock
> ordering). Some drivers (libxl, lxc, qemu, and vz) handle the
> not enough references by adding an virObjectRef to the object
> returned from the Add code, while others (bhyve, openvz, test,
> uml, and vmware) live rather vicariously and carefully, but at
> least don't reference the object after calling Remove.
> 
> Fixing all this will take a few patch streams across a few
> mostly dormant driver modules and some coordination with the
> vir*FindBy{UUID|ID|Name} logic. Some of that was already posted
> previously, but only received minimal notice:
> 
> https://www.redhat.com/archives/libvir-list/2018-March/msg00489.html
> 
> So rather than (re)posting a 20-30 patch series on list which
> probably won't get reviewed, I'll take things in smaller batches
> of patches in the hopes that all this can be worked through so
> that the end result is "cleaner" (and agreed upon).
> 
> John Ferlan (4):
>   conf: Fix error path logic in virDomainObjListAddLocked
>   conf: Fix error path logic in virDomainObjListLoadStatus
>   conf: Introduce virDomainObjListAddObjLocked
>   conf: Fix virDomainObjParseFile object handling
> 
>  src/conf/virdomainobjlist.c | 63 
> -
>  src/lxc/lxc_controller.c|  2 +-
>  tests/qemuxml2xmltest.c |  2 +-
>  3 files changed, 42 insertions(+), 25 deletions(-)
> 

ACK series.

Michal

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

Re: [libvirt] [PATCH 0/2] Two almost trivial fixes

[Ján Tomko]

On Fri, Apr 06, 2018 at 02:22:45PM +0200, Michal Privoznik wrote:

Any review appreciated.

Michal Privoznik (2):
 storageVolLookupData: Drop conn struct member
 storageDriverAutostart: Drop unused @conn

src/storage/storage_driver.c | 9 ++---
src/test/test_driver.c   | 5 ++---
2 files changed, 4 insertions(+), 10 deletions(-)



ACK

Jano


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

[libvirt] [PATCH 0/2] Two almost trivial fixes

[Michal Privoznik]

Any review appreciated.

Michal Privoznik (2):
  storageVolLookupData: Drop conn struct member
  storageDriverAutostart: Drop unused @conn

 src/storage/storage_driver.c | 9 ++---
 src/test/test_driver.c   | 5 ++---
 2 files changed, 4 insertions(+), 10 deletions(-)

-- 
2.16.1

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

[libvirt] [PATCH 1/2] storageVolLookupData: Drop conn struct member

[Michal Privoznik]

Since its introduction in 5d5c732d748d64 it has been never used.

Signed-off-by: Michal Privoznik 
---
 src/storage/storage_driver.c | 5 ++---
 src/test/test_driver.c   | 5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index d5e38af5aa..6ddead1b95 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -1520,7 +1520,6 @@ storageVolLookupByName(virStoragePoolPtr pool,
 
 
 struct storageVolLookupData {
-virConnectPtr conn;
 const char *key;
 char *cleanpath;
 const char *path;
@@ -1547,7 +1546,7 @@ storageVolLookupByKey(virConnectPtr conn,
 virStoragePoolObjPtr obj;
 virStoragePoolDefPtr def;
 struct storageVolLookupData data = {
-.conn = conn, .key = key, .voldef = NULL };
+.key = key, .voldef = NULL };
 virStorageVolPtr vol = NULL;
 
 if ((obj = virStoragePoolObjListSearch(driver->pools,
@@ -1627,7 +1626,7 @@ storageVolLookupByPath(virConnectPtr conn,
 virStoragePoolObjPtr obj;
 virStoragePoolDefPtr def;
 struct storageVolLookupData data = {
-.conn = conn, .path = path, .voldef = NULL };
+.path = path, .voldef = NULL };
 virStorageVolPtr vol = NULL;
 
 if (!(data.cleanpath = virFileSanitizePath(path)))
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 5e39ae574c..856869c9d3 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -5026,7 +5026,6 @@ testStorageVolLookupByName(virStoragePoolPtr pool,
 
 
 struct storageVolLookupData {
-virConnectPtr conn;
 const char *key;
 const char *path;
 virStorageVolDefPtr voldef;
@@ -5053,7 +5052,7 @@ testStorageVolLookupByKey(virConnectPtr conn,
 virStoragePoolObjPtr obj;
 virStoragePoolDefPtr def;
 struct storageVolLookupData data = {
-.conn = conn, .key = key, .voldef = NULL };
+.key = key, .voldef = NULL };
 virStorageVolPtr vol = NULL;
 
 testDriverLock(privconn);
@@ -5097,7 +5096,7 @@ testStorageVolLookupByPath(virConnectPtr conn,
 virStoragePoolObjPtr obj;
 virStoragePoolDefPtr def;
 struct storageVolLookupData data = {
-.conn = conn, .path = path, .voldef = NULL };
+.path = path, .voldef = NULL };
 virStorageVolPtr vol = NULL;
 
 testDriverLock(privconn);
-- 
2.16.1

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

[libvirt] [PATCH 2/2] storageDriverAutostart: Drop unused @conn

[Michal Privoznik]

This variable is not actually used in the function. Especially
after 31869efe2a8.

Signed-off-by: Michal Privoznik 
---
 src/storage/storage_driver.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index 6ddead1b95..173b91b61b 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -218,13 +218,9 @@ storageDriverAutostartCallback(virStoragePoolObjPtr obj,
 static void
 storageDriverAutostart(void)
 {
-virConnectPtr conn = NULL;
-
 virStoragePoolObjListForEach(driver->pools,
  storageDriverAutostartCallback,
  NULL);
-
-virObjectUnref(conn);
 }
 
 /**
-- 
2.16.1

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

Re: [libvirt] [PATCH 02/68] qemu: Rename qemuMigrationAnyCapsGet as qemuMigrationCapsGet

[Ján Tomko]

On Wed, Apr 04, 2018 at 04:40:51PM +0200, Jiri Denemark wrote:

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c|  4 ++--
src/qemu/qemu_migration.c | 10 +-
src/qemu/qemu_migration.h |  4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c


ACK

Jano


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

Re: [libvirt] [PATCH 03/68] qemu: Rename qemuMigrationParams

[Ján Tomko]

On Wed, Apr 04, 2018 at 04:40:52PM +0200, Jiri Denemark wrote:

The function is now called qemuMigrationParamsFromFlags to better
reflect what it is doing: taking migration flags and params and
producing a struct with QEMU migration parameters.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c| 2 +-
src/qemu/qemu_migration.c | 6 +++---
src/qemu/qemu_migration.h | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)



ACK

Jano


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

Re: [libvirt] [jenkins-ci PATCH 02/10] guests: Enable ~/.bashrc on FreeBSD

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:12PM +0200, Andrea Bolognani wrote:
> Due to the way bash is compiled on FreeBSD, we need to flip an
> extra switch in order to convince it to process the shell profile
> even when we're running commands non-interactively through ssh.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/tasks/kludges.yml | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/guests/tasks/kludges.yml b/guests/tasks/kludges.yml
> index 001b5c6..0196559 100644
> --- a/guests/tasks/kludges.yml
> +++ b/guests/tasks/kludges.yml
> @@ -29,3 +29,21 @@
>when:
>  - os_name == 'FreeBSD'
>  - os_version == '11'
> +
> +# FreeBSD compiles bash without defining SSH_SOURCE_BASHRC, which means
> +# it won't try to detect when it's spawned by ssh and source ~/.bashrc
> +# when that's the case. Our workaround is setting $BASH_ENV globally

s/globally/globally./

Reviewed-by: Pavel Hrdina 


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

[libvirt] [jenkins-ci PATCH 1/3] guests: Drop CentOS 6 support

[Andrea Bolognani]

Signed-off-by: Andrea Bolognani 
---
 guests/host_vars/libvirt-centos-6/install.yml |  3 -
 guests/host_vars/libvirt-centos-6/main.yml|  9 ---
 guests/inventory  |  1 -
 guests/vars/mappings.yml  | 16 +
 guests/vars/projects/libvirt.yml  |  1 -
 guests/vars/vault.yml | 86 +--
 6 files changed, 42 insertions(+), 74 deletions(-)
 delete mode 100644 guests/host_vars/libvirt-centos-6/install.yml
 delete mode 100644 guests/host_vars/libvirt-centos-6/main.yml

diff --git a/guests/host_vars/libvirt-centos-6/install.yml 
b/guests/host_vars/libvirt-centos-6/install.yml
deleted file mode 100644
index 3a9459b..000
--- a/guests/host_vars/libvirt-centos-6/install.yml
+++ /dev/null
@@ -1,3 +0,0 @@

-install_url: http://mirror.centos.org/centos/6/os/x86_64/
-install_config: kickstart.cfg
diff --git a/guests/host_vars/libvirt-centos-6/main.yml 
b/guests/host_vars/libvirt-centos-6/main.yml
deleted file mode 100644
index 422d033..000
--- a/guests/host_vars/libvirt-centos-6/main.yml
+++ /dev/null
@@ -1,9 +0,0 @@

-PERL5LIB: $VIRT_PREFIX/lib64/perl5
-PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages
-
-projects:
-  - libvirt
-  - libvirt-cim
-  - libvirt-perl
-  - libvirt-python
diff --git a/guests/inventory b/guests/inventory
index 41826ee..4e69dcb 100644
--- a/guests/inventory
+++ b/guests/inventory
@@ -1,4 +1,3 @@
-libvirt-centos-6
 libvirt-centos-7
 libvirt-debian-8
 libvirt-debian-9
diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index cb44b3d..0e29a1b 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -9,7 +9,7 @@
 #   - default
 #   - package format (deb, pkg, rpm)
 #   - OS name (CentOS, Debian, Fedora, FreeBSD, Ubuntu)
-#   - OS version (CentOS6, Debian9, FedoraRawhide, Ubuntu14 and so on)
+#   - OS version (CentOS7, Debian9, FedoraRawhide, Ubuntu14 and so on)
 #
 # So something like
 #
@@ -58,7 +58,6 @@ mappings:
 
   bash-completion:
 default: bash-completion
-CentOS6:
 
   ccache:
 default: ccache
@@ -145,20 +144,17 @@ mappings:
   go:
 default: golang
 FreeBSD: go
-CentOS6:
 Ubuntu14:
 
   gobject-introspection:
 deb: libgirepository1.0-dev
 pkg: gobject-introspection
 rpm: gobject-introspection-devel
-CentOS6:
 
   gtk3:
 deb: libgtk-3-dev
 pkg: gtk3
 rpm: gtk3-devel
-CentOS6:
 
   gtk-doc:
 default: gtk-doc
@@ -168,7 +164,6 @@ mappings:
 deb: libgtk-vnc-2.0-dev
 pkg: gtk-vnc
 rpm: gtk-vnc2-devel
-CentOS6:
 
   hal:
 FreeBSD: hal
@@ -234,9 +229,6 @@ mappings:
 Debian: libgovirt-dev
 Debian8:
 
-  libnl:
-CentOS6: libnl-devel
-
   libnl3:
 deb: libnl-3-dev
 rpm: libnl3-devel
@@ -282,7 +274,6 @@ mappings:
 rpm: libssh-devel
 Debian: libssh-gcrypt-dev
 Ubuntu: libssh-dev
-CentOS6:
 
   libssh2:
 deb: libssh2-1-dev
@@ -436,7 +427,6 @@ mappings:
 deb: libcpan-changes-perl
 pkg: p5-CPAN-Changes
 rpm: perl-CPAN-Changes
-CentOS6:
 
   perl-Config-Record:
 deb: libconfig-record-perl
@@ -447,13 +437,11 @@ mappings:
 deb: libdigest-perl
 pkg: p5-Digest
 rpm: perl-Digest
-CentOS6:
 
   perl-Digest-MD5:
 deb: libdigest-perl-md5-perl
 pkg: p5-Digest-MD5
 rpm: perl-Digest-MD5
-CentOS6:
 Ubuntu14:
 
   perl-ExtUtils-MakeMaker:
@@ -657,7 +645,6 @@ mappings:
 deb: libspice-client-gtk-3.0-dev
 pkg: spice-gtk
 rpm: spice-gtk3-devel
-CentOS6:
 
   sudo:
 default: sudo
@@ -673,7 +660,6 @@ mappings:
   vala:
 default: vala
 deb: valac
-CentOS6:
 
   vim:
 default: vim
diff --git a/guests/vars/projects/libvirt.yml b/guests/vars/projects/libvirt.yml
index 9f027f8..8cfe077 100644
--- a/guests/vars/projects/libvirt.yml
+++ b/guests/vars/projects/libvirt.yml
@@ -22,7 +22,6 @@ packages:
   - libcap-ng
   - libcurl
   - libdbus
-  - libnl
   - libnl3
   - libnlroute3
   - libnuma
diff --git a/guests/vars/vault.yml b/guests/vars/vault.yml
index 5b5504e..15ef76f 100644
--- a/guests/vars/vault.yml
+++ b/guests/vars/vault.yml
@@ -1,46 +1,42 @@
 $ANSIBLE_VAULT;1.1;AES256
-65383961343931383034323931343431663863336439383062306134393231613032306466383066
-6466656433353431303462383737323537323462313864300a653135633963393336386431376434
-3738633864363638633463396163653063643731663934633265343861316538313639363564
-3663663762396333630a316534323362663861626563366561643237326663653664316565663236
-3334343534366235363562333663613331303039373462636230616430623235383634616464
-3562363236306330666338363962653664326234636435363533346231623364386563663334
-32376332623932663838316662306463663365343438366537343065663834373237626135626137
-3531366164353539663231323936303539313237313535623366343232663539646461393965
-66306261653664323733613266333732663434653839653236656264613634356335626635323833

[libvirt] [jenkins-ci PATCH 2/3] projects: Drop CentOS 6 support

[Andrea Bolognani]

Signed-off-by: Andrea Bolognani 
---
 projects/libvirt-cim.yaml| 1 -
 projects/libvirt-perl.yaml   | 1 -
 projects/libvirt-python.yaml | 2 --
 projects/libvirt.yaml| 3 ---
 4 files changed, 7 deletions(-)

diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml
index c1a0914..160faaf 100644
--- a/projects/libvirt-cim.yaml
+++ b/projects/libvirt-cim.yaml
@@ -2,7 +2,6 @@
 - project:
 name: libvirt-cim
 machines:
-  - libvirt-centos-6
   - libvirt-centos-7
   - libvirt-fedora-26
   - libvirt-fedora-27
diff --git a/projects/libvirt-perl.yaml b/projects/libvirt-perl.yaml
index 3912876..eb1ee77 100644
--- a/projects/libvirt-perl.yaml
+++ b/projects/libvirt-perl.yaml
@@ -2,7 +2,6 @@
 - project:
 name: libvirt-perl
 machines:
-  - libvirt-centos-6
   - libvirt-centos-7
   - libvirt-debian-8
   - libvirt-debian-9
diff --git a/projects/libvirt-python.yaml b/projects/libvirt-python.yaml
index dd8ac13..26accf4 100644
--- a/projects/libvirt-python.yaml
+++ b/projects/libvirt-python.yaml
@@ -2,7 +2,6 @@
 - project:
 name: libvirt-python
 machines:
-  - libvirt-centos-6
   - libvirt-centos-7
   - libvirt-debian-8
   - libvirt-debian-9
@@ -20,7 +19,6 @@
   - python-distutils-rpm-job:
   parent_jobs: 'libvirt-python-master-check'
   machines:
-- libvirt-centos-6
 - libvirt-centos-7
 - libvirt-fedora-26
 - libvirt-fedora-27
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
index 13f39f9..4fcf849 100644
--- a/projects/libvirt.yaml
+++ b/projects/libvirt.yaml
@@ -2,7 +2,6 @@
 - project:
 name: libvirt
 machines:
-  - libvirt-centos-6
   - libvirt-centos-7
   - libvirt-debian-8
   - libvirt-debian-9
@@ -15,7 +14,6 @@
   - autotools-build-job:
   parent_jobs:
   machines:
-- libvirt-centos-6
 - libvirt-centos-7
 - libvirt-debian-8
 - libvirt-debian-9
@@ -34,7 +32,6 @@
   - autotools-rpm-job:
   parent_jobs: 'libvirt-master-check'
   machines:
-- libvirt-centos-6
 - libvirt-centos-7
 - libvirt-fedora-26
 - libvirt-fedora-27
-- 
2.14.3

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

[libvirt] [jenkins-ci PATCH 0/3] Drop CentOS 6, which makes some nice cleanups possible

[Andrea Bolognani]

This applies on top of

  https://www.redhat.com/archives/libvir-list/2018-April/msg00410.html

and, of course, should only be pushed after

  https://www.redhat.com/archives/libvir-list/2018-April/msg00326.html

or a follow-up version has been pushed.

Andrea Bolognani (3):
  guests: Drop CentOS 6 support
  projects: Drop CentOS 6 support
  jobs: Introduce {all_machines} and {rpm_machines}

 guests/host_vars/libvirt-centos-6/install.yml |  3 -
 guests/host_vars/libvirt-centos-6/main.yml|  9 ---
 guests/inventory  |  1 -
 guests/vars/mappings.yml  | 16 +
 guests/vars/projects/libvirt.yml  |  1 -
 guests/vars/vault.yml | 86 +--
 jobs/defaults.yaml| 14 +
 projects/libosinfo.yaml   | 16 +
 projects/libvirt-cim.yaml |  7 +--
 projects/libvirt-glib.yaml| 16 +
 projects/libvirt-go-xml.yaml  | 10 +---
 projects/libvirt-go.yaml  | 10 +---
 projects/libvirt-perl.yaml| 17 +-
 projects/libvirt-python.yaml  | 18 +-
 projects/libvirt.yaml | 30 --
 projects/osinfo-db-tools.yaml | 16 +
 projects/osinfo-db.yaml   | 16 +
 projects/virt-viewer.yaml | 16 +
 18 files changed, 84 insertions(+), 218 deletions(-)
 delete mode 100644 guests/host_vars/libvirt-centos-6/install.yml
 delete mode 100644 guests/host_vars/libvirt-centos-6/main.yml

-- 
2.14.3

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

[libvirt] [jenkins-ci PATCH 3/3] jobs: Introduce {all_machines} and {rpm_machines}

[Andrea Bolognani]

We're running most of the jobs on all machines, with the major
notable exception being the various *-rpm jobs which of course
only make sense for RPM-based distributions.

Instead of listing machines over and over again, define two
list globally and refer to them by name. Ad-hoc machine lists
are still needed in a few places, but overall this cuts down on
repetition significantly.

Signed-off-by: Andrea Bolognani 
---
 jobs/defaults.yaml| 14 ++
 projects/libosinfo.yaml   | 16 ++--
 projects/libvirt-cim.yaml |  6 +-
 projects/libvirt-glib.yaml| 16 ++--
 projects/libvirt-go-xml.yaml  | 10 +-
 projects/libvirt-go.yaml  | 10 +-
 projects/libvirt-perl.yaml| 16 ++--
 projects/libvirt-python.yaml  | 16 ++--
 projects/libvirt.yaml | 27 +++
 projects/osinfo-db-tools.yaml | 16 ++--
 projects/osinfo-db.yaml   | 16 ++--
 projects/virt-viewer.yaml | 16 ++--
 12 files changed, 42 insertions(+), 137 deletions(-)

diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml
index 23f8555..9fe69de 100644
--- a/jobs/defaults.yaml
+++ b/jobs/defaults.yaml
@@ -3,6 +3,20 @@
 name: global
 branch: master
 node: libvirt
+all_machines:
+  - libvirt-centos-7
+  - libvirt-debian-8
+  - libvirt-debian-9
+  - libvirt-fedora-26
+  - libvirt-fedora-27
+  - libvirt-fedora-rawhide
+  - libvirt-freebsd-10
+  - libvirt-freebsd-11
+rpm_machines:
+  - libvirt-centos-7
+  - libvirt-fedora-26
+  - libvirt-fedora-27
+  - libvirt-fedora-rawhide
 global_env: |
 local_env: |
 smp: 3
diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml
index ac04027..0d25447 100644
--- a/projects/libosinfo.yaml
+++ b/projects/libosinfo.yaml
@@ -1,15 +1,7 @@
 
 - project:
 name: libosinfo
-machines:
-  - libvirt-centos-7
-  - libvirt-debian-8
-  - libvirt-debian-9
-  - libvirt-fedora-26
-  - libvirt-fedora-27
-  - libvirt-fedora-rawhide
-  - libvirt-freebsd-10
-  - libvirt-freebsd-11
+machines: '{all_machines}'
 title: libosinfo
 jobs:
   - autotools-build-job:
@@ -20,8 +12,4 @@
   parent_jobs: 'libosinfo-master-syntax-check'
   - autotools-rpm-job:
   parent_jobs: 'libosinfo-master-check'
-  machines:
-- libvirt-centos-7
-- libvirt-fedora-26
-- libvirt-fedora-27
-- libvirt-fedora-rawhide
+  machines: '{rpm_machines}'
diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml
index 160faaf..dff3976 100644
--- a/projects/libvirt-cim.yaml
+++ b/projects/libvirt-cim.yaml
@@ -1,11 +1,7 @@
 
 - project:
 name: libvirt-cim
-machines:
-  - libvirt-centos-7
-  - libvirt-fedora-26
-  - libvirt-fedora-27
-  - libvirt-fedora-rawhide
+machines: '{rpm_machines}'
 title: libvirt CIM
 jobs:
   - autotools-build-job:
diff --git a/projects/libvirt-glib.yaml b/projects/libvirt-glib.yaml
index 74f7642..741ac44 100644
--- a/projects/libvirt-glib.yaml
+++ b/projects/libvirt-glib.yaml
@@ -1,15 +1,7 @@
 
 - project:
 name: libvirt-glib
-machines:
-  - libvirt-centos-7
-  - libvirt-debian-8
-  - libvirt-debian-9
-  - libvirt-fedora-26
-  - libvirt-fedora-27
-  - libvirt-fedora-rawhide
-  - libvirt-freebsd-10
-  - libvirt-freebsd-11
+machines: '{all_machines}'
 title: Libvirt GLib
 jobs:
   - autotools-build-job:
@@ -21,8 +13,4 @@
   parent_jobs: 'libvirt-glib-master-syntax-check'
   - autotools-rpm-job:
   parent_jobs: 'libvirt-glib-master-check'
-  machines:
-- libvirt-centos-7
-- libvirt-fedora-26
-- libvirt-fedora-27
-- libvirt-fedora-rawhide
+  machines: '{rpm_machines}'
diff --git a/projects/libvirt-go-xml.yaml b/projects/libvirt-go-xml.yaml
index 126058b..1f26751 100644
--- a/projects/libvirt-go-xml.yaml
+++ b/projects/libvirt-go-xml.yaml
@@ -1,15 +1,7 @@
 
 - project:
 name: libvirt-go-xml
-machines:
-  - libvirt-centos-7
-  - libvirt-debian-8
-  - libvirt-debian-9
-  - libvirt-fedora-26
-  - libvirt-fedora-27
-  - libvirt-fedora-rawhide
-  - libvirt-freebsd-10
-  - libvirt-freebsd-11
+machines: '{all_machines}'
 title: Libvirt Go XML
 local_env: |
   export TEST_ARGS="-tags xmlroundtrip"
diff --git a/projects/libvirt-go.yaml b/projects/libvirt-go.yaml
index 141c862..f40f523 100644
--- a/projects/libvirt-go.yaml
+++ b/projects/libvirt-go.yaml
@@ -1,15 +1,7 @@
 
 - project:
 name: libvirt-go
-machines:
-  - libvirt-centos-7
-  - libvirt-debian-8
-  - libvirt-debian-9
-  - libvirt-fedora-26
-  - libvirt-fedora-27
-  - libvirt-fedora-rawhide
-  - libvirt-freebsd-10
-  - 

Re: [libvirt] [dbus PATCH 0/9] Add more properties and methods for Network

[Katerina Koukiou]

On Fri, 2018-04-06 at 13:20 +0200, Katerina Koukiou wrote:
> Katerina Koukiou (9):
>   tests: Rename minimal_xml to minimal_domain_xml
>   Add Domain prefix to CreateXML method, test and related functions.

I broke tests with this, and I didn't realize because of the known
issue with non propagating Exceptions from handlers. Will fix and
repost.

>   Add Domain prefix to DefineXML method, tests and related functions.
>   Implement NetworkCreateXML method for Connect interface
>   Implement NetworkDefineXML method for Connect interface
>   Implement GetXMLDesc method for Network Interface.
>   Implement Active property for Network Interface.
>   Implement Persistent property for Network Interface.
>   Implement Setter for Autostart property of Network Interface.
> 
>  data/org.libvirt.Connect.xml | 16 +++-
>  data/org.libvirt.Network.xml | 19 -
>  src/connect.c| 90
> ++
>  src/network.c| 94
> +++-
>  test/test_connect.py | 48 +++---
>  test/test_network.py | 15 +++
>  6 files changed, 256 insertions(+), 26 deletions(-)
> 

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

Re: [libvirt] [jenkins-ci PATCH 01/10] guests: Rename compat -> kludges

[Pavel Hrdina]

On Thu, Apr 05, 2018 at 02:22:11PM +0200, Andrea Bolognani wrote:
> This task only contains workarounds that we shouldn't have to
> worry about to begin with, and that hopefully in due time we'll
> be able to drop entirely. Rename it to make this more apparent.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/site.yml  | 2 +-
>  guests/tasks/{compat.yml => kludges.yml} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename guests/tasks/{compat.yml => kludges.yml} (100%)

Reviewed-by: Pavel Hrdina 


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

[libvirt] [jenkins-ci PATCH 11/10] guests: Move $OSINFO_SYSTEM_DIR configuration to shell profile

[Andrea Bolognani]

This belongs with all the other enviroment settings, but it was
somehow missed the first time around.

Signed-off-by: Andrea Bolognani 
---
 guests/group_vars/all/main.yml | 1 +
 guests/templates/bashrc| 1 +
 projects/libosinfo.yaml| 2 --
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/guests/group_vars/all/main.yml b/guests/group_vars/all/main.yml
index 4229e73..2bdb7b3 100644
--- a/guests/group_vars/all/main.yml
+++ b/guests/group_vars/all/main.yml
@@ -17,6 +17,7 @@ LD_LIBRARY_PATH: $VIRT_PREFIX/lib
 PKG_CONFIG_PATH: $VIRT_PREFIX/lib/pkgconfig
 XDG_DATA_DIRS: $VIRT_PREFIX/share:/usr/share:/usr/local/share
 GI_TYPELIB_PATH: $VIRT_PREFIX/lib/girepository-1.0
+OSINFO_SYSTEM_DIR: $VIRT_PREFIX/share/osinfo
 PERL5LIB:
 PYTHONPATH:
 
diff --git a/guests/templates/bashrc b/guests/templates/bashrc
index 95bb172..639a961 100644
--- a/guests/templates/bashrc
+++ b/guests/templates/bashrc
@@ -7,6 +7,7 @@ export LD_LIBRARY_PATH="{{ LD_LIBRARY_PATH }}"
 export PKG_CONFIG_PATH="{{ PKG_CONFIG_PATH }}"
 export XDG_DATA_DIRS="{{ XDG_DATA_DIRS }}"
 export GI_TYPELIB_PATH="{{ GI_TYPELIB_PATH }}"
+export OSINFO_SYSTEM_DIR="{{ OSINFO_SYSTEM_DIR }}"
 export PERL5LIB="{{ PERL5LIB }}"
 export PYTHONPATH="{{ PYTHONPATH }}"
 
diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml
index efe66c9..ac04027 100644
--- a/projects/libosinfo.yaml
+++ b/projects/libosinfo.yaml
@@ -11,8 +11,6 @@
   - libvirt-freebsd-10
   - libvirt-freebsd-11
 title: libosinfo
-local_env: |
-  export OSINFO_SYSTEM_DIR=$VIRT_PREFIX/share/osinfo
 jobs:
   - autotools-build-job:
   parent_jobs: 'osinfo-db-master-build'
-- 
2.14.3

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

Re: [libvirt] [PATCH 06/11] qemu: Implement pcie-to-pci-bridge controller

[John Ferlan]

On 04/06/2018 04:15 AM, Andrea Bolognani wrote:
> On Wed, 2018-04-04 at 10:58 +0200, Andrea Bolognani wrote:
>> On Tue, 2018-04-03 at 19:13 -0400, John Ferlan wrote:
>>> Is there something else perhaps a few paragraphs later that could be
>>> added to say what this is and how/when/why someone should want to use
>>> it? Including the restriction about slot=0 (whatever the FLA SHPC is)...
>>> Similar to dmi-to-pci-bridge... Perhaps something that would already be
>>> there considering my patch 1 comment for a description field or some
>>> sort of relationship matrix...
>>
>> Yeah, I realized today that there's some documentation for the
>> existing behavior of adding a dmi-to-pci-bridge that will need to
>> tweaked in this patch to address the changes... Once that's been
>> taken care of, I don't think there will be much to add, though.
> 
> I've come up with the diff below, which I plan to squash in patch
> 8/11, when the change in behavior it documents is implemented. I
> have also converted the list of models to a , as agreed upon in
> the review for patch 1/11.
> 
> Since patch 3/11 is really just an independent cleanup which doesn't
> need to hold up the new feature, I plan to go ahead and push the
> rest of the series (with the changes described above) later today.
> Is that okay with you, or would you rather see a full v2 posted on
> the list?
> 

Your plan is fine by me.

John

> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 84059737d5..a5a83f56c3 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -4114,10 +4114,14 @@
>devices (although libvirt will never auto-assign a PCI device to
>a PCIe slot, it will allow manual specification of such an
>assignment). Devices connected to pcie-root cannot be
> -  hotplugged. In order to make standard PCI slots available on a
> -  system which has a pcie-root controller, a pci controller
> -  with model='dmi-to-pci-bridge' is automatically
> -  added, usually at the defacto standard location of slot=0x1e. A
> +  hotplugged. If traditional PCI devices are present in the guest
> +  configuration, a pcie-to-pci-bridge controller will
> +  automatically be added: this controller, which plugs into a
> +  pcie-root-port, provides 31 usable PCI slots (1-31) with
> +  hotplug support (since 4.3.0). If the QEMU
> +  binary doesn't support the corresponding device, then a
> +  dmi-to-pci-bridge controller will be added instead,
> +  usually at the defacto standard location of slot=0x1e. A
>dmi-to-pci-bridge controller plugs into a PCIe slot (as provided
>by pcie-root), and itself provides 31 standard PCI slots (which
>also do not support device hotplug). In order to have
> 

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

Re: [libvirt] [PATCH 0/2] Change virCloseCallback typedef to return void

[John Ferlan]

ping?

Tks -

John

On 03/29/2018 08:48 AM, John Ferlan wrote:
> Slightly related to some current work to clean up the Add/Remove
> domain object list processing - as it turns out the close callbacks
> run code didn't even pay attention to what was returned and it
> really didn't need to - so let's just call it what it is a void
> function and let the virCloseCallbacksRun code handle the object
> manipulation (lock/ref and unlock/unref).
> 
> John Ferlan (2):
>   qemu: Fix qemuProcessAutoDestroy
>   util: Alter virCloseCallback typedef to return void
> 
>  src/bhyve/bhyve_process.c|  8 ++--
>  src/lxc/lxc_process.c|  8 ++--
>  src/qemu/qemu_migration.c|  7 ++-
>  src/qemu/qemu_process.c  | 10 ++
>  src/util/virclosecallbacks.c |  5 ++---
>  src/util/virclosecallbacks.h |  6 +++---
>  6 files changed, 13 insertions(+), 31 deletions(-)
> 

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

Re: [libvirt] [PATCH 2/6] tpm: Add support for external swtpm TPM emulator

[Stefan Berger]

On 04/06/2018 04:26 AM, Daniel P. Berrangé wrote:

On Thu, Apr 05, 2018 at 05:56:02PM -0400, Stefan Berger wrote:

This patch adds support for an external swtpm TPM emulator. The XML for
this type of TPM looks as follows:

  

  

The XML will currently only start a TPM 1.2.

Upon the first start, libvirt will run `swtpm_setup`, which will simulate the
manufacturing of a TPM and create certificates for it and write them into the
NVRAM location of the emulated TPM.

Then, libvirt will automatically start the swtpm TPM emulator using the `swtpm`
executable.

Once the VM terminates, libvirt uses the swtpm_ioctl executable to gracefully
shut down the `swtpm` in case it is still running (QEMU did not send shutdown)
or clean up the socket file.

The above mentioned executables must be found in the PATH.

The executables can either be run as root or started as root and switch to
the tss user. The requirement for the tss user comes through 'tcsd', which
is used for the simulation of the manufacturing. Which user is used can be
configured through qemu.conf.

The swtpm writes out state into files. The state is kept in 
/var/lib/libvirt/tpm:

[root@localhost libvirt]# ls -lZ | grep tpm

drwx--x--x. 7 root root unconfined_u:object_r:virt_var_lib_t:s0 4096 Apr  5 
16:22 tpm

The directory /var/lib/libvirt/tpm maintains per-TPM state directories but
also hosts the UnixIO socket of running swtpms, which QEMU uses for 
communicating
with them. At this point only the socket file is labeled properly and made 
accessible
for QEMU, which runs under the qemu user:

/var/lib is for persistent state while /var/run is for transient
state, so I think sockets should be under /var/run instead.


/var/run/libvirt/qemu then ?





[root@localhost tpm]# ls -lZ
total 4
drwx--. 2 tss  tss  system_u:object_r:virt_var_lib_t:s0  4096 Apr  
5 16:46 485d0004-a48f-436a-8457-8a3b73e28567
srw---. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c413,c4300 Apr  
5 16:46 485d0004-a48f-436a-8457-8a3b73e28567.sock

[root@localhost 485d0004-a48f-436a-8457-8a3b73e28567]# ls -lZ
total 8
-rw-r--r--. 1 tss tss system_u:object_r:virt_var_lib_t:s0 3648 Apr  5 16:46 
tpm-00.permall
-rw-r--r--. 1 tss tss system_u:object_r:virt_var_lib_t:s0 2237 Apr  5 16:46 
vtpm.log

root@sbct-3 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep swtpm | grep 
-v grep
system_u:system_r:virtd_t:s0-s0:c0.c1023 tss 18697 0.0  0.0 28172 3892 ?   
Ss   16:46   0:00 /usr/bin/swtpm socket --daemon --ctrl 
type=unixio,path=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567.sock,mode=0600
 --tpmstate dir=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567 --log 
file=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567/vtpm.log --runas 
59

[root@sbct-3 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep qemu | grep 
tpm | grep -v grep
system_u:system_r:svirt_t:s0:c413,c430 qemu 18702 2.5  0.0 3036052 48676 ? 
Sl   16:46   0:08 /bin/qemu-system-x86_64 -name 
guest=centos7.0,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-centos7.0/master-key.aes
 -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu kvm64 -m 
2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
485d0004-a48f-436a-8457-8a3b73e28567 [...] -tpmdev 
emulator,id=tpm-tpm0,chardev=chrtpm -chardev 
socket,id=chrtpm,path=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567.sock
 -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 -device 
usb-mouse,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device 
cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on

Signed-off-by: Stefan Berger 
---
  docs/formatdomain.html.in  |  30 ++
  docs/schemas/domaincommon.rng  |   5 +
  src/conf/domain_audit.c|   2 +
  src/conf/domain_conf.c |  51 ++-
  src/conf/domain_conf.h |   5 +
  src/libvirt_private.syms   |   5 +
  src/qemu/Makefile.inc.am   |   2 +
  src/qemu/libvirtd_qemu.aug |   3 +
  src/qemu/qemu.conf |   7 +
  src/qemu/qemu_capabilities.c   |   5 +
  src/qemu/qemu_capabilities.h   |   1 +
  src/qemu/qemu_cgroup.c |   1 +
  src/qemu/qemu_command.c|  52 ++-
  src/qemu/qemu_conf.c   |  11 +-
  src/qemu/qemu_conf.h   |   2 +
  src/qemu/qemu_domain.c |   2 +
  src/qemu/qemu_driver.c |  13 +
  src/qemu/qemu_extdevice.c  | 195 ++
  src/qemu/qemu_extdevice.h  |  36 ++
  src/qemu/qemu_process.c|   8 +
  

[libvirt] [dbus PATCH 4/9] Implement NetworkCreateXML method for Connect interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Connect.xml |  6 ++
 src/connect.c| 29 +
 test/test_connect.py | 26 ++
 3 files changed, 61 insertions(+)

diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
index 715aeef..5f5c5fe 100644
--- a/data/org.libvirt.Connect.xml
+++ b/data/org.libvirt.Connect.xml
@@ -50,6 +50,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkCreateXML"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkLookupByName"/>
diff --git a/src/connect.c b/src/connect.c
index 9931c8f..759b9fb 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -330,6 +330,34 @@ virtDBusConnectListNetworks(GVariant *inArgs,
 *outArgs = g_variant_new_tuple(, 1);
 }
 
+static void
+virtDBusConnectNetworkCreateXML(GVariant *inArgs,
+GUnixFDList *inFDs G_GNUC_UNUSED,
+const gchar *objectPath G_GNUC_UNUSED,
+gpointer userData,
+GVariant **outArgs,
+GUnixFDList **outFDs G_GNUC_UNUSED,
+GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virNetwork) network = NULL;
+g_autofree gchar *path = NULL;
+gchar *xml;
+
+g_variant_get(inArgs, "()", );
+
+if (!virtDBusConnectOpen(connect, error))
+return;
+
+network = virNetworkCreateXML(connect->connection, xml);
+if (!network)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirNetwork(network, connect->domainPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
 static void
 virtDBusNetworkLookupByName(GVariant *inArgs,
 GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -399,6 +427,7 @@ static virtDBusGDBusMethodTable 
virtDBusConnectMethodTable[] = {
 { "DomainLookupByName", virtDBusDomainLookupByName },
 { "DomainLookupByUUID", virtDBusDomainLookupByUUID },
 { "ListNetworks", virtDBusConnectListNetworks },
+{ "NetworkCreateXML", virtDBusConnectNetworkCreateXML },
 { "NetworkLookupByName", virtDBusNetworkLookupByName },
 { "NetworkLookupByUUID", virtDBusNetworkLookupByUUID },
 { 0 }
diff --git a/test/test_connect.py b/test/test_connect.py
index 394f812..e3b493b 100755
--- a/test/test_connect.py
+++ b/test/test_connect.py
@@ -16,6 +16,20 @@ class TestConnect(libvirttest.BaseTestClass):
 
 '''
 
+minimal_network_xml = '''
+
+  bar
+  004b96e12d78c30f5aa5f03c87d21e69
+  
+  
+  
+
+  
+
+  
+
+'''
+
 def test_list_domains(self):
 domains = self.connect.ListDomains(0)
 assert isinstance(domains, dbus.Array)
@@ -86,6 +100,18 @@ class TestConnect(libvirttest.BaseTestClass):
 # ensure the path exists by calling Introspect on it
 network.Introspect(dbus_interface=dbus.INTROSPECTABLE_IFACE)
 
+def test_connect_network_create_xml(self):
+def network_started(path, _event):
+assert isinstance(path, dbus.ObjectPath)
+self.loop.quit()
+
+self.connect.connect_to_signal('NetworkEvent', network_started, 
arg1='Started')
+
+path = self.connect.NetworkCreateXML(self.minimal_network_xml)
+assert isinstance(path, dbus.ObjectPath)
+
+self.main_loop()
+
 @pytest.mark.parametrize("lookup_method_name,lookup_item", [
 ("NetworkLookupByName", 'Name'),
 ("NetworkLookupByUUID", 'UUID'),
-- 
2.15.0

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

[libvirt] [dbus PATCH 0/9] Add more properties and methods for Network

[Katerina Koukiou]

Katerina Koukiou (9):
  tests: Rename minimal_xml to minimal_domain_xml
  Add Domain prefix to CreateXML method, test and related functions.
  Add Domain prefix to DefineXML method, tests and related functions.
  Implement NetworkCreateXML method for Connect interface
  Implement NetworkDefineXML method for Connect interface
  Implement GetXMLDesc method for Network Interface.
  Implement Active property for Network Interface.
  Implement Persistent property for Network Interface.
  Implement Setter for Autostart property of Network Interface.

 data/org.libvirt.Connect.xml | 16 +++-
 data/org.libvirt.Network.xml | 19 -
 src/connect.c| 90 ++
 src/network.c| 94 +++-
 test/test_connect.py | 48 +++---
 test/test_network.py | 15 +++
 6 files changed, 256 insertions(+), 26 deletions(-)

-- 
2.15.0

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

[libvirt] [dbus PATCH 8/9] Implement Persistent property for Network Interface.

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Network.xml |  4 
 src/network.c| 22 ++
 test/test_network.py |  1 +
 3 files changed, 27 insertions(+)

diff --git a/data/org.libvirt.Network.xml b/data/org.libvirt.Network.xml
index cadf0a8..863f4d2 100644
--- a/data/org.libvirt.Network.xml
+++ b/data/org.libvirt.Network.xml
@@ -19,6 +19,10 @@
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkGetName"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkIsPersistent"/>
+
 
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkGetUUIDString"/>
diff --git a/src/network.c b/src/network.c
index 7f0091a..5ca1379 100644
--- a/src/network.c
+++ b/src/network.c
@@ -108,6 +108,27 @@ virtDBusNetworkGetName(const gchar *objectPath,
 *value = g_variant_new("s", name);
 }
 
+static void
+virtDBusNetworkGetPersistent(const gchar *objectPath,
+ gpointer userData,
+ GVariant **value,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virNetwork) network = NULL;
+gint persistent;
+
+network = virtDBusNetworkGetVirNetwork(connect, objectPath, error);
+if (!network)
+return;
+
+persistent = virNetworkIsPersistent(network);
+if (persistent < 0)
+return virtDBusUtilSetLastVirtError(error);
+
+*value = g_variant_new("b", !!persistent);
+}
+
 static void
 virtDBusNetworkGetUUID(const gchar *objectPath,
gpointer userData,
@@ -220,6 +241,7 @@ static virtDBusGDBusPropertyTable 
virtDBusNetworkPropertyTable[] = {
 { "Autostart", virtDBusNetworkGetAutostart, NULL },
 { "BridgeName", virtDBusNetworkGetBridgeName, NULL },
 { "Name", virtDBusNetworkGetName, NULL },
+{ "Persistent", virtDBusNetworkGetPersistent, NULL },
 { "UUID", virtDBusNetworkGetUUID, NULL },
 { 0 }
 };
diff --git a/test/test_network.py b/test/test_network.py
index 4180cc8..a5987e5 100755
--- a/test/test_network.py
+++ b/test/test_network.py
@@ -16,6 +16,7 @@ class TestNetwork(libvirttest.BaseTestClass):
 assert isinstance(props['Autostart'], dbus.Boolean)
 assert isinstance(props['BridgeName'], dbus.String)
 assert isinstance(props['Name'], dbus.String)
+assert isinstance(props['Persistent'], dbus.Boolean)
 assert isinstance(props['UUID'], dbus.String)
 
 def test_network_create(self):
-- 
2.15.0

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

[libvirt] [dbus PATCH 9/9] Implement Setter for Autostart property of Network Interface.

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Network.xml |  5 +++--
 src/network.c| 22 +-
 test/test_network.py |  8 
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/data/org.libvirt.Network.xml b/data/org.libvirt.Network.xml
index 863f4d2..1d89ae3 100644
--- a/data/org.libvirt.Network.xml
+++ b/data/org.libvirt.Network.xml
@@ -7,9 +7,10 @@
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkIsActive"/>
 
-
+
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkGetAutostart"/>
+  value="See 
https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkGetAutostart and
+ 
https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkSetAutostart"/>
 
 
   https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/4] Initial phase of domain obj add/remove cleanup

[John Ferlan]

ping?

Tks -

John

On 03/29/2018 08:34 AM, John Ferlan wrote:
> As evidenced by various code comments, the process of adding and
> removing objects to/from the domain object list is problematic.
> 
> Long story short is that the Add logic doesn't generate enough
> object references and the Remove logic removes one extra than
> was added during Add and leaves the object unlocked upon return
> (as well as doing a small fire dance to ensure proper lock
> ordering). Some drivers (libxl, lxc, qemu, and vz) handle the
> not enough references by adding an virObjectRef to the object
> returned from the Add code, while others (bhyve, openvz, test,
> uml, and vmware) live rather vicariously and carefully, but at
> least don't reference the object after calling Remove.
> 
> Fixing all this will take a few patch streams across a few
> mostly dormant driver modules and some coordination with the
> vir*FindBy{UUID|ID|Name} logic. Some of that was already posted
> previously, but only received minimal notice:
> 
> https://www.redhat.com/archives/libvir-list/2018-March/msg00489.html
> 
> So rather than (re)posting a 20-30 patch series on list which
> probably won't get reviewed, I'll take things in smaller batches
> of patches in the hopes that all this can be worked through so
> that the end result is "cleaner" (and agreed upon).
> 
> John Ferlan (4):
>   conf: Fix error path logic in virDomainObjListAddLocked
>   conf: Fix error path logic in virDomainObjListLoadStatus
>   conf: Introduce virDomainObjListAddObjLocked
>   conf: Fix virDomainObjParseFile object handling
> 
>  src/conf/virdomainobjlist.c | 63 
> -
>  src/lxc/lxc_controller.c|  2 +-
>  tests/qemuxml2xmltest.c |  2 +-
>  3 files changed, 42 insertions(+), 25 deletions(-)
> 

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

[libvirt] [dbus PATCH 6/9] Implement GetXMLDesc method for Network Interface.

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Network.xml |  6 ++
 src/network.c| 28 
 test/test_network.py |  5 +
 3 files changed, 39 insertions(+)

diff --git a/data/org.libvirt.Network.xml b/data/org.libvirt.Network.xml
index 46198fe..456217a 100644
--- a/data/org.libvirt.Network.xml
+++ b/data/org.libvirt.Network.xml
@@ -27,6 +27,12 @@
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkDestroy"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkGetXMLDesc"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkUndefine"/>
diff --git a/src/network.c b/src/network.c
index bb385d3..bd9e86a 100644
--- a/src/network.c
+++ b/src/network.c
@@ -147,6 +147,33 @@ virtDBusNetworkDestroy(GVariant *inArgs G_GNUC_UNUSED,
 virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusNetworkGetXMLDesc(GVariant *inArgs,
+  GUnixFDList *inFDs G_GNUC_UNUSED,
+  const gchar *objectPath,
+  gpointer userData,
+  GVariant **outArgs,
+  GUnixFDList **outFDs G_GNUC_UNUSED,
+  GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virNetwork) network = NULL;
+g_autofree gchar *xml = NULL;
+guint flags;
+
+g_variant_get(inArgs, "(u)", );
+
+network = virtDBusNetworkGetVirNetwork(connect, objectPath, error);
+if (!network)
+return;
+
+xml = virNetworkGetXMLDesc(network, flags);
+if (!xml)
+return virtDBusUtilSetLastVirtError(error);
+
+*outArgs = g_variant_new("(s)", xml);
+}
+
 static void
 virtDBusNetworkUndefine(GVariant *inArgs G_GNUC_UNUSED,
 GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -178,6 +205,7 @@ static virtDBusGDBusPropertyTable 
virtDBusNetworkPropertyTable[] = {
 static virtDBusGDBusMethodTable virtDBusNetworkMethodTable[] = {
 { "Create", virtDBusNetworkCreate },
 { "Destroy", virtDBusNetworkDestroy },
+{ "GetXMLDesc", virtDBusNetworkGetXMLDesc },
 { "Undefine", virtDBusNetworkUndefine },
 { 0 }
 };
diff --git a/test/test_network.py b/test/test_network.py
index 8ec54ad..397fc0c 100755
--- a/test/test_network.py
+++ b/test/test_network.py
@@ -44,6 +44,11 @@ class TestNetwork(libvirttest.BaseTestClass):
 
 self.main_loop()
 
+def test_network_get_xml_description(self):
+_,test_network = self.test_network()
+interface_obj = dbus.Interface(test_network, 'org.libvirt.Network')
+assert isinstance(interface_obj.GetXMLDesc(0), dbus.String)
+
 def test_network_undefine(self):
 def domain_undefined(path, _event):
 assert isinstance(path, dbus.ObjectPath)
-- 
2.15.0

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

Re: [libvirt] [PATCH v2 0/9] Be consistent with vir*Obj*Remove* APIs

[John Ferlan]

ping?

Tks -

John

On 03/28/2018 05:19 PM, John Ferlan wrote:
> v1: https://www.redhat.com/archives/libvir-list/2018-March/msg01295.html
> 
> NB: This can wait until 4.2.0 is release, but I figured I'd post this
> now just to put it on the radar and of course in hopes that someone
> will look during the idle moment or two before the release.
> 
> Changes since v1:
> 
>  Short story: Rework the processing of the code
> 
>  Longer story:
> 
>  In his review Erik noted that there's a "fire dance" when processing
>  the vir*Obj*Remove APIs of requiring a locked object upon entry, then
>  adding a reference to that object, unlocking the object, locking the
>  list to which it is contained, and then relocking the object.
> 
>  So it took some time to think about it and during one lengthy meeting
>  today I had the aha moment that the *Remove API's could take the same
>  key (e.g., uuid or name) used to Add or Find the object and use it for
>  the Remove API. This allows the Remove API to not require a locked (and
>  reffed) object upon entry and perform the lock dance, remove the object,
>  and return just just a reffed object forcing the caller to know to Unref
>  object.
> 
>  Instead, let's simplify things. The *Remove API can take the key, Find
>  the object in the list, remove it from the hash tables, and dispose of
>  the object. In essence the antecedent to the Add or AssignDef API's
>  taking a def, creating an object, and adding it the object to the hash
>  table(s). If there are two *Remove threads competing, one will win and
>  perform the removal, while the other will call *Remove, but won't find
>  the object in the hash table, and just return none the wiser.
> 
>  And yes, I think this can also work for the Domain code, but it's going
>  to take a few patch series to get there as that code is not consistent
>  between consumers.
> 
> John Ferlan (9):
>   secret: Rework LoadAllConfigs
>   secret: Alter virSecretObjListRemove processing
>   interface: Alter virInterfaceObjListRemove processing
>   nodedev: Alter virNodeDeviceObjListRemove processing
>   conf: Clean up virStoragePoolObjLoad error processing
>   storage: Clean up storagePoolCreateXML error processing
>   test: Clean up testStoragePoolCreateXML error processing
>   conf: Move virStoragePoolObjRemove closer to AssignDef
>   storagepool: Alter virStoragePoolObjRemove processing
> 
>  src/conf/virinterfaceobj.c | 26 +++
>  src/conf/virinterfaceobj.h |  2 +-
>  src/conf/virnodedeviceobj.c| 29 +++-
>  src/conf/virnodedeviceobj.h|  2 +-
>  src/conf/virsecretobj.c| 58 +++-
>  src/conf/virsecretobj.h|  2 +-
>  src/conf/virstorageobj.c   | 92 
> +++---
>  src/conf/virstorageobj.h   |  2 +-
>  src/node_device/node_device_hal.c  | 16 ---
>  src/node_device/node_device_udev.c | 13 --
>  src/secret/secret_driver.c | 15 ---
>  src/storage/storage_driver.c   | 65 +++
>  src/test/test_driver.c | 78 +---
>  13 files changed, 225 insertions(+), 175 deletions(-)
> 

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

[libvirt] [dbus PATCH 5/9] Implement NetworkDefineXML method for Connect interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Connect.xml |  6 ++
 src/connect.c| 29 +
 test/test_connect.py | 12 
 3 files changed, 47 insertions(+)

diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
index 5f5c5fe..e36b7f6 100644
--- a/data/org.libvirt.Connect.xml
+++ b/data/org.libvirt.Connect.xml
@@ -56,6 +56,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkDefineXML"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkLookupByName"/>
diff --git a/src/connect.c b/src/connect.c
index 759b9fb..3a0e969 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -358,6 +358,34 @@ virtDBusConnectNetworkCreateXML(GVariant *inArgs,
 *outArgs = g_variant_new("(o)", path);
 }
 
+static void
+virtDBusConnectNetworkDefineXML(GVariant *inArgs,
+GUnixFDList *inFDs G_GNUC_UNUSED,
+const gchar *objectPath G_GNUC_UNUSED,
+gpointer userData,
+GVariant **outArgs,
+GUnixFDList **outFDs G_GNUC_UNUSED,
+GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virNetwork) network = NULL;
+g_autofree gchar *path = NULL;
+gchar *xml;
+
+g_variant_get(inArgs, "()", );
+
+if (!virtDBusConnectOpen(connect, error))
+return;
+
+network = virNetworkDefineXML(connect->connection, xml);
+if (!network)
+return virtDBusUtilSetLastVirtError(error);
+
+path = virtDBusUtilBusPathForVirNetwork(network, connect->networkPath);
+
+*outArgs = g_variant_new("(o)", path);
+}
+
 static void
 virtDBusNetworkLookupByName(GVariant *inArgs,
 GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -428,6 +456,7 @@ static virtDBusGDBusMethodTable 
virtDBusConnectMethodTable[] = {
 { "DomainLookupByUUID", virtDBusDomainLookupByUUID },
 { "ListNetworks", virtDBusConnectListNetworks },
 { "NetworkCreateXML", virtDBusConnectNetworkCreateXML },
+{ "NetworkDefineXML", virtDBusConnectNetworkDefineXML },
 { "NetworkLookupByName", virtDBusNetworkLookupByName },
 { "NetworkLookupByUUID", virtDBusNetworkLookupByUUID },
 { 0 }
diff --git a/test/test_connect.py b/test/test_connect.py
index e3b493b..c411eeb 100755
--- a/test/test_connect.py
+++ b/test/test_connect.py
@@ -112,6 +112,18 @@ class TestConnect(libvirttest.BaseTestClass):
 
 self.main_loop()
 
+def test_connect_network_define_xml(self):
+def network_defined(path, _event):
+assert isinstance(path, dbus.ObjectPath)
+self.loop.quit()
+
+self.connect.connect_to_signal('NetworkEvent', network_defined, 
arg1='Defined')
+
+path = self.connect.NetworkDefineXML(self.minimal_network_xml)
+assert isinstance(path, dbus.ObjectPath)
+
+self.main_loop()
+
 @pytest.mark.parametrize("lookup_method_name,lookup_item", [
 ("NetworkLookupByName", 'Name'),
 ("NetworkLookupByUUID", 'UUID'),
-- 
2.15.0

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

[libvirt] [dbus PATCH 7/9] Implement Active property for Network Interface.

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Network.xml |  4 
 src/network.c| 22 ++
 test/test_network.py |  1 +
 3 files changed, 27 insertions(+)

diff --git a/data/org.libvirt.Network.xml b/data/org.libvirt.Network.xml
index 456217a..cadf0a8 100644
--- a/data/org.libvirt.Network.xml
+++ b/data/org.libvirt.Network.xml
@@ -3,6 +3,10 @@
 
 
   
+
+  https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkIsActive"/>
+
 
   https://libvirt.org/html/libvirt-libvirt-network.html#virNetworkGetAutostart"/>
diff --git a/src/network.c b/src/network.c
index bd9e86a..7f0091a 100644
--- a/src/network.c
+++ b/src/network.c
@@ -24,6 +24,27 @@ virtDBusNetworkGetVirNetwork(virtDBusConnect *connect,
 return network;
 }
 
+static void
+virtDBusNetworkGetActive(const gchar *objectPath,
+ gpointer userData,
+ GVariant **value,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virNetwork) network = NULL;
+gint active;
+
+network = virtDBusNetworkGetVirNetwork(connect, objectPath, error);
+if (!network)
+return;
+
+active = virNetworkIsActive(network);
+if (active < 0)
+return virtDBusUtilSetLastVirtError(error);
+
+*value = g_variant_new("b", !!active);
+}
+
 static void
 virtDBusNetworkGetAutostart(const gchar *objectPath,
 gpointer userData,
@@ -195,6 +216,7 @@ virtDBusNetworkUndefine(GVariant *inArgs G_GNUC_UNUSED,
 }
 
 static virtDBusGDBusPropertyTable virtDBusNetworkPropertyTable[] = {
+{ "Active", virtDBusNetworkGetActive, NULL },
 { "Autostart", virtDBusNetworkGetAutostart, NULL },
 { "BridgeName", virtDBusNetworkGetBridgeName, NULL },
 { "Name", virtDBusNetworkGetName, NULL },
diff --git a/test/test_network.py b/test/test_network.py
index 397fc0c..4180cc8 100755
--- a/test/test_network.py
+++ b/test/test_network.py
@@ -12,6 +12,7 @@ class TestNetwork(libvirttest.BaseTestClass):
 """
 _, obj = self.test_network()
 props = obj.GetAll('org.libvirt.Network', 
dbus_interface=dbus.PROPERTIES_IFACE)
+assert isinstance(props['Active'], dbus.Boolean)
 assert isinstance(props['Autostart'], dbus.Boolean)
 assert isinstance(props['BridgeName'], dbus.String)
 assert isinstance(props['Name'], dbus.String)
-- 
2.15.0

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

[libvirt] [dbus PATCH 2/9] Add Domain prefix to CreateXML method, test and related functions.

[Katerina Koukiou]

This method is domain specific and should be clear from the naming,
so that we can later define *CreateXML methods for other entities.

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Connect.xml |  2 +-
 src/connect.c| 16 
 test/test_connect.py |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
index 6aa07f6..c29076d 100644
--- a/data/org.libvirt.Connect.xml
+++ b/data/org.libvirt.Connect.xml
@@ -13,7 +13,7 @@
   
   
 
-
+
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainCreateXML"/>
   
diff --git a/src/connect.c b/src/connect.c
index 85c85ee..3715d25 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -150,13 +150,13 @@ virtDBusConnectListDomains(GVariant *inArgs,
 }
 
 static void
-virtDBusConnectCreateXML(GVariant *inArgs,
- GUnixFDList *inFDs G_GNUC_UNUSED,
- const gchar *objectPath G_GNUC_UNUSED,
- gpointer userData,
- GVariant **outArgs,
- GUnixFDList **outFDs G_GNUC_UNUSED,
- GError **error)
+virtDBusConnectDomainCreateXML(GVariant *inArgs,
+   GUnixFDList *inFDs G_GNUC_UNUSED,
+   const gchar *objectPath G_GNUC_UNUSED,
+   gpointer userData,
+   GVariant **outArgs,
+   GUnixFDList **outFDs G_GNUC_UNUSED,
+   GError **error)
 {
 virtDBusConnect *connect = userData;
 g_autoptr(virDomain) domain = NULL;
@@ -393,7 +393,7 @@ static virtDBusGDBusPropertyTable 
virtDBusConnectPropertyTable[] = {
 
 static virtDBusGDBusMethodTable virtDBusConnectMethodTable[] = {
 { "ListDomains", virtDBusConnectListDomains },
-{ "CreateXML", virtDBusConnectCreateXML },
+{ "DomainCreateXML", virtDBusConnectDomainCreateXML },
 { "DefineXML", virtDBusConnectDefineXML },
 { "DomainLookupByID", virtDBusDomainLookupByID },
 { "DomainLookupByName", virtDBusDomainLookupByName },
diff --git a/test/test_connect.py b/test/test_connect.py
index 5436a29..2b2031d 100755
--- a/test/test_connect.py
+++ b/test/test_connect.py
@@ -28,14 +28,14 @@ class TestConnect(libvirttest.BaseTestClass):
 # ensure the path exists by calling Introspect on it
 domain.Introspect(dbus_interface=dbus.INTROSPECTABLE_IFACE)
 
-def test_create(self):
+def test_connect_domain_create_xml(self):
 def domain_started(path, _event):
 assert isinstance(path, dbus.ObjectPath)
 self.loop.quit()
 
 self.connect.connect_to_signal('DomainEvent', domain_started, 
arg1='Started')
 
-path = self.connect.CreateXML(self.minimal_domain_xml, 0)
+path = self.connect.DomainCreateXML(self.minimal_domain_xml, 0)
 assert isinstance(path, dbus.ObjectPath)
 
 self.main_loop()
-- 
2.15.0

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

[libvirt] [dbus PATCH 3/9] Add Domain prefix to DefineXML method, tests and related functions.

[Katerina Koukiou]

This method is domain specific and should be clear from the naming,
so that we can later define *DefineXML methods for other entities.

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Connect.xml |  2 +-
 src/connect.c| 16 
 test/test_connect.py |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/data/org.libvirt.Connect.xml b/data/org.libvirt.Connect.xml
index c29076d..715aeef 100644
--- a/data/org.libvirt.Connect.xml
+++ b/data/org.libvirt.Connect.xml
@@ -20,7 +20,7 @@
   
   
 
-
+
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainDefineXML"/>
   
diff --git a/src/connect.c b/src/connect.c
index 3715d25..9931c8f 100644
--- a/src/connect.c
+++ b/src/connect.c
@@ -179,13 +179,13 @@ virtDBusConnectDomainCreateXML(GVariant *inArgs,
 }
 
 static void
-virtDBusConnectDefineXML(GVariant *inArgs,
- GUnixFDList *inFDs G_GNUC_UNUSED,
- const gchar *objectPath G_GNUC_UNUSED,
- gpointer userData,
- GVariant **outArgs,
- GUnixFDList **outFDs G_GNUC_UNUSED,
- GError **error)
+virtDBusConnectDomainDefineXML(GVariant *inArgs,
+   GUnixFDList *inFDs G_GNUC_UNUSED,
+   const gchar *objectPath G_GNUC_UNUSED,
+   gpointer userData,
+   GVariant **outArgs,
+   GUnixFDList **outFDs G_GNUC_UNUSED,
+   GError **error)
 {
 virtDBusConnect *connect = userData;
 g_autoptr(virDomain) domain = NULL;
@@ -394,7 +394,7 @@ static virtDBusGDBusPropertyTable 
virtDBusConnectPropertyTable[] = {
 static virtDBusGDBusMethodTable virtDBusConnectMethodTable[] = {
 { "ListDomains", virtDBusConnectListDomains },
 { "DomainCreateXML", virtDBusConnectDomainCreateXML },
-{ "DefineXML", virtDBusConnectDefineXML },
+{ "DomainDefineXML", virtDBusConnectDomainDefineXML },
 { "DomainLookupByID", virtDBusDomainLookupByID },
 { "DomainLookupByName", virtDBusDomainLookupByName },
 { "DomainLookupByUUID", virtDBusDomainLookupByUUID },
diff --git a/test/test_connect.py b/test/test_connect.py
index 2b2031d..394f812 100755
--- a/test/test_connect.py
+++ b/test/test_connect.py
@@ -40,14 +40,14 @@ class TestConnect(libvirttest.BaseTestClass):
 
 self.main_loop()
 
-def test_define(self):
+def test_comnect_domain_define_xml(self):
 def domain_defined(path, _event):
 assert isinstance(path, dbus.ObjectPath)
 self.loop.quit()
 
 self.connect.connect_to_signal('DomainEvent', domain_defined, 
arg1='Defined')
 
-path = self.connect.DefineXML(self.minimal_domain_xml)
+path = self.connect.DomainDefineXML(self.minimal_domain_xml)
 assert isinstance(path, dbus.ObjectPath)
 
 self.main_loop()
-- 
2.15.0

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

[libvirt] [dbus PATCH 1/9] tests: Rename minimal_xml to minimal_domain_xml

[Katerina Koukiou]

Needed so as to keep consistent naming when we 'll introduce XML
for other entities.

Signed-off-by: Katerina Koukiou 
---
 test/test_connect.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/test_connect.py b/test/test_connect.py
index 79402b8..5436a29 100755
--- a/test/test_connect.py
+++ b/test/test_connect.py
@@ -6,7 +6,7 @@ import pytest
 
 
 class TestConnect(libvirttest.BaseTestClass):
-minimal_xml = '''
+minimal_domain_xml = '''
 
   foo
   1024
@@ -35,7 +35,7 @@ class TestConnect(libvirttest.BaseTestClass):
 
 self.connect.connect_to_signal('DomainEvent', domain_started, 
arg1='Started')
 
-path = self.connect.CreateXML(self.minimal_xml, 0)
+path = self.connect.CreateXML(self.minimal_domain_xml, 0)
 assert isinstance(path, dbus.ObjectPath)
 
 self.main_loop()
@@ -47,7 +47,7 @@ class TestConnect(libvirttest.BaseTestClass):
 
 self.connect.connect_to_signal('DomainEvent', domain_defined, 
arg1='Defined')
 
-path = self.connect.DefineXML(self.minimal_xml)
+path = self.connect.DefineXML(self.minimal_domain_xml)
 assert isinstance(path, dbus.ObjectPath)
 
 self.main_loop()
-- 
2.15.0

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

Re: [libvirt] [PATCH] util: don't check for parallel iteration in hash-related functions

[Michal Privoznik]

On 04/06/2018 09:56 AM, Vincent Bernat wrote:
> This is the responsability of the caller to apply the correct lock
> before using these functions. Moreover, the use of a simple boolean
> was still racy: two threads may check the boolean and "lock" it
> simultaneously.
> 
> Users of functions from src/util/virhash.c have to be checked for
> correctness. Lookups and iteration should hold a RO
> lock. Modifications should hold a RW lock.
> 
> Most important uses seem to be covered. Callers have now a greater
> responsability, notably the ability to execute some operations while
> iterating were reliably forbidden before are now accepted.
> ---
>  src/util/virhash.c  | 37 --
>  tests/virhashtest.c | 75 -
>  2 files changed, 112 deletions(-)

So I went through all callbacks (even transitive ones) and I've found
two problems:

umlProcessAutoDestroyRun -> umlProcessAutoDestroyDom -> virHashRemoveEntry

qemuDomainSnapshotDiscardAllMetadata -> qemuDomainSnapshotDiscardAll ->
qemuDomainSnapshotDiscard -> virDomainSnapshotObjListRemove ->
virHashRemoveEntry

While me (and probably Peter :-)) don't care about the first one, the
second one is a real issue. I guess we need to fix that one before this
can be merged.

On a positive side, I haven't spotted any other problem. So once qemu
(and possibly uml) are fixed this can be merged as is.

Michal

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

Re: [libvirt] [PATCH 2/6] tpm: Add support for external swtpm TPM emulator

[Daniel P . Berrangé]

On Thu, Apr 05, 2018 at 05:56:02PM -0400, Stefan Berger wrote:
> This patch adds support for an external swtpm TPM emulator. The XML for
> this type of TPM looks as follows:
> 
>  
>
>  
> 
> The XML will currently only start a TPM 1.2.
> 
> Upon the first start, libvirt will run `swtpm_setup`, which will simulate the
> manufacturing of a TPM and create certificates for it and write them into the
> NVRAM location of the emulated TPM.
> 
> Then, libvirt will automatically start the swtpm TPM emulator using the 
> `swtpm`
> executable.
> 
> Once the VM terminates, libvirt uses the swtpm_ioctl executable to gracefully
> shut down the `swtpm` in case it is still running (QEMU did not send shutdown)
> or clean up the socket file.
> 
> The above mentioned executables must be found in the PATH.
> 
> The executables can either be run as root or started as root and switch to
> the tss user. The requirement for the tss user comes through 'tcsd', which
> is used for the simulation of the manufacturing. Which user is used can be
> configured through qemu.conf.
> 
> The swtpm writes out state into files. The state is kept in 
> /var/lib/libvirt/tpm:
> 
> [root@localhost libvirt]# ls -lZ | grep tpm
> 
> drwx--x--x. 7 root root unconfined_u:object_r:virt_var_lib_t:s0 4096 Apr  5 
> 16:22 tpm
> 
> The directory /var/lib/libvirt/tpm maintains per-TPM state directories but
> also hosts the UnixIO socket of running swtpms, which QEMU uses for 
> communicating
> with them. At this point only the socket file is labeled properly and made 
> accessible
> for QEMU, which runs under the qemu user:

/var/lib is for persistent state while /var/run is for transient
state, so I think sockets should be under /var/run instead.

> 
> [root@localhost tpm]# ls -lZ
> total 4
> drwx--. 2 tss  tss  system_u:object_r:virt_var_lib_t:s0  4096 Apr 
>  5 16:46 485d0004-a48f-436a-8457-8a3b73e28567
> srw---. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c413,c4300 Apr 
>  5 16:46 485d0004-a48f-436a-8457-8a3b73e28567.sock
> 
> [root@localhost 485d0004-a48f-436a-8457-8a3b73e28567]# ls -lZ
> total 8
> -rw-r--r--. 1 tss tss system_u:object_r:virt_var_lib_t:s0 3648 Apr  5 16:46 
> tpm-00.permall
> -rw-r--r--. 1 tss tss system_u:object_r:virt_var_lib_t:s0 2237 Apr  5 16:46 
> vtpm.log
> 
> root@sbct-3 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep swtpm | 
> grep -v grep
> system_u:system_r:virtd_t:s0-s0:c0.c1023 tss 18697 0.0  0.0 28172 3892 ?  
>  Ss   16:46   0:00 /usr/bin/swtpm socket --daemon --ctrl 
> type=unixio,path=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567.sock,mode=0600
>  --tpmstate dir=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567 
> --log file=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567/vtpm.log 
> --runas 59
> 
> [root@sbct-3 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep qemu | 
> grep tpm | grep -v grep
> system_u:system_r:svirt_t:s0:c413,c430 qemu 18702 2.5  0.0 3036052 48676 ?
>  Sl   16:46   0:08 /bin/qemu-system-x86_64 -name 
> guest=centos7.0,debug-threads=on -S -object 
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-centos7.0/master-key.aes
>  -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu kvm64 -m 
> 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
> 485d0004-a48f-436a-8457-8a3b73e28567 [...] -tpmdev 
> emulator,id=tpm-tpm0,chardev=chrtpm -chardev 
> socket,id=chrtpm,path=/var/lib/libvirt/tpm/485d0004-a48f-436a-8457-8a3b73e28567.sock
>  -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 -device 
> usb-mouse,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device 
> cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on
> 
> Signed-off-by: Stefan Berger 
> ---
>  docs/formatdomain.html.in  |  30 ++
>  docs/schemas/domaincommon.rng  |   5 +
>  src/conf/domain_audit.c|   2 +
>  src/conf/domain_conf.c |  51 ++-
>  src/conf/domain_conf.h |   5 +
>  src/libvirt_private.syms   |   5 +
>  src/qemu/Makefile.inc.am   |   2 +
>  src/qemu/libvirtd_qemu.aug |   3 +
>  src/qemu/qemu.conf |   7 +
>  src/qemu/qemu_capabilities.c   |   5 +
>  src/qemu/qemu_capabilities.h   |   1 +
>  src/qemu/qemu_cgroup.c |   1 +
>  src/qemu/qemu_command.c|  52 ++-
>  src/qemu/qemu_conf.c   |  11 +-
>  src/qemu/qemu_conf.h   |   2 +
>  src/qemu/qemu_domain.c |   2 +
>  src/qemu/qemu_driver.c |  13 +
>  src/qemu/qemu_extdevice.c  | 195 ++
>  src/qemu/qemu_extdevice.h   

Re: [libvirt] [PATCH 06/11] qemu: Implement pcie-to-pci-bridge controller

[Andrea Bolognani]

On Wed, 2018-04-04 at 10:58 +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 19:13 -0400, John Ferlan wrote:
> > Is there something else perhaps a few paragraphs later that could be
> > added to say what this is and how/when/why someone should want to use
> > it? Including the restriction about slot=0 (whatever the FLA SHPC is)...
> > Similar to dmi-to-pci-bridge... Perhaps something that would already be
> > there considering my patch 1 comment for a description field or some
> > sort of relationship matrix...
> 
> Yeah, I realized today that there's some documentation for the
> existing behavior of adding a dmi-to-pci-bridge that will need to
> tweaked in this patch to address the changes... Once that's been
> taken care of, I don't think there will be much to add, though.

I've come up with the diff below, which I plan to squash in patch
8/11, when the change in behavior it documents is implemented. I
have also converted the list of models to a , as agreed upon in
the review for patch 1/11.

Since patch 3/11 is really just an independent cleanup which doesn't
need to hold up the new feature, I plan to go ahead and push the
rest of the series (with the changes described above) later today.
Is that okay with you, or would you rather see a full v2 posted on
the list?


diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 84059737d5..a5a83f56c3 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -4114,10 +4114,14 @@
   devices (although libvirt will never auto-assign a PCI device to
   a PCIe slot, it will allow manual specification of such an
   assignment). Devices connected to pcie-root cannot be
-  hotplugged. In order to make standard PCI slots available on a
-  system which has a pcie-root controller, a pci controller
-  with model='dmi-to-pci-bridge' is automatically
-  added, usually at the defacto standard location of slot=0x1e. A
+  hotplugged. If traditional PCI devices are present in the guest
+  configuration, a pcie-to-pci-bridge controller will
+  automatically be added: this controller, which plugs into a
+  pcie-root-port, provides 31 usable PCI slots (1-31) with
+  hotplug support (since 4.3.0). If the QEMU
+  binary doesn't support the corresponding device, then a
+  dmi-to-pci-bridge controller will be added instead,
+  usually at the defacto standard location of slot=0x1e. A
   dmi-to-pci-bridge controller plugs into a PCIe slot (as provided
   by pcie-root), and itself provides 31 standard PCI slots (which
   also do not support device hotplug). In order to have
-- 
Andrea Bolognani / Red Hat / Virtualization

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

[libvirt] [PATCH] util: don't check for parallel iteration in hash-related functions

[Vincent Bernat]

This is the responsability of the caller to apply the correct lock
before using these functions. Moreover, the use of a simple boolean
was still racy: two threads may check the boolean and "lock" it
simultaneously.

Users of functions from src/util/virhash.c have to be checked for
correctness. Lookups and iteration should hold a RO
lock. Modifications should hold a RW lock.

Most important uses seem to be covered. Callers have now a greater
responsability, notably the ability to execute some operations while
iterating were reliably forbidden before are now accepted.
---
 src/util/virhash.c  | 37 --
 tests/virhashtest.c | 75 -
 2 files changed, 112 deletions(-)

diff --git a/src/util/virhash.c b/src/util/virhash.c
index 0ffbfcce2c64..475c2b0281b2 100644
--- a/src/util/virhash.c
+++ b/src/util/virhash.c
@@ -41,12 +41,6 @@ VIR_LOG_INIT("util.hash");
 
 /* #define DEBUG_GROW */
 
-#define virHashIterationError(ret) \
-do { \
-VIR_ERROR(_("Hash operation not allowed during iteration")); \
-return ret; \
-} while (0)
-
 /*
  * A single entry in the hash table
  */
@@ -66,10 +60,6 @@ struct _virHashTable {
 uint32_t seed;
 size_t size;
 size_t nbElems;
-/* True iff we are iterating over hash entries. */
-bool iterating;
-/* Pointer to the current entry during iteration. */
-virHashEntryPtr current;
 virHashDataFree dataFree;
 virHashKeyCode keyCode;
 virHashKeyEqual keyEqual;
@@ -339,9 +329,6 @@ virHashAddOrUpdateEntry(virHashTablePtr table, const void 
*name,
 if ((table == NULL) || (name == NULL))
 return -1;
 
-if (table->iterating)
-virHashIterationError(-1);
-
 key = virHashComputeKey(table, name);
 
 /* Check for duplicate entry */
@@ -551,9 +538,6 @@ virHashRemoveEntry(virHashTablePtr table, const void *name)
 nextptr = table->table + virHashComputeKey(table, name);
 for (entry = *nextptr; entry; entry = entry->next) {
 if (table->keyEqual(entry->name, name)) {
-if (table->iterating && table->current != entry)
-virHashIterationError(-1);
-
 if (table->dataFree)
 table->dataFree(entry->payload, entry->name);
 if (table->keyFree)
@@ -593,18 +577,11 @@ virHashForEach(virHashTablePtr table, virHashIterator 
iter, void *data)
 if (table == NULL || iter == NULL)
 return -1;
 
-if (table->iterating)
-virHashIterationError(-1);
-
-table->iterating = true;
-table->current = NULL;
 for (i = 0; i < table->size; i++) {
 virHashEntryPtr entry = table->table[i];
 while (entry) {
 virHashEntryPtr next = entry->next;
-table->current = entry;
 ret = iter(entry->payload, entry->name, data);
-table->current = NULL;
 
 if (ret < 0)
 goto cleanup;
@@ -615,7 +592,6 @@ virHashForEach(virHashTablePtr table, virHashIterator iter, 
void *data)
 
 ret = 0;
  cleanup:
-table->iterating = false;
 return ret;
 }
 
@@ -643,11 +619,6 @@ virHashRemoveSet(virHashTablePtr table,
 if (table == NULL || iter == NULL)
 return -1;
 
-if (table->iterating)
-virHashIterationError(-1);
-
-table->iterating = true;
-table->current = NULL;
 for (i = 0; i < table->size; i++) {
 virHashEntryPtr *nextptr = table->table + i;
 
@@ -667,7 +638,6 @@ virHashRemoveSet(virHashTablePtr table,
 }
 }
 }
-table->iterating = false;
 
 return count;
 }
@@ -723,23 +693,16 @@ void *virHashSearch(const virHashTable *ctable,
 if (table == NULL || iter == NULL)
 return NULL;
 
-if (table->iterating)
-virHashIterationError(NULL);
-
-table->iterating = true;
-table->current = NULL;
 for (i = 0; i < table->size; i++) {
 virHashEntryPtr entry;
 for (entry = table->table[i]; entry; entry = entry->next) {
 if (iter(entry->payload, entry->name, data)) {
-table->iterating = false;
 if (name)
 *name = table->keyCopy(entry->name);
 return entry->payload;
 }
 }
 }
-table->iterating = false;
 
 return NULL;
 }
diff --git a/tests/virhashtest.c b/tests/virhashtest.c
index 3b85b62c301d..a013bc716943 100644
--- a/tests/virhashtest.c
+++ b/tests/virhashtest.c
@@ -221,32 +221,6 @@ testHashRemoveForEachAll(void *payload ATTRIBUTE_UNUSED,
 }
 
 
-const int testHashCountRemoveForEachForbidden = ARRAY_CARDINALITY(uuids);
-
-static int
-testHashRemoveForEachForbidden(void *payload ATTRIBUTE_UNUSED,
-   const void *name,
-   void *data)
-{
-virHashTablePtr hash = data;
-size_t i;
-
-for (i = 0; i < ARRAY_CARDINALITY(uuids_subset); i++) {
-if (STREQ(uuids_subset[i], name)) {
-int next = (i + 1) %