https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

This change catches an invalid use of the option in our
test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

This change catches an invalid use of the option in our
test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

The existing function is renamed and called from the new one, so
that even while we're in the process of implementing new checks
all the existing ones will be performed.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

In remoteConnectOpen, conn->uri cannot be NULL in the second
part of the OR expression due to short-circuit evaluation.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

In qemuMigrationSrcRun, we already checked for non-NULL mig
and then dereferenced it. It's only possible for mig to be
NULL in the error section.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

If a system has sasl GSSAPI plugin available qemu with sasl support will
try to read /etc/gss/mech.d/.

It is required to allow that to let the modules fully work and it should
be safe to do so as it only registers/configures plugins but has no secrets.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Acked-by: NJamie Strandboge <jamie@canonical.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Bitwise or just looks wrong here.
Introduced by <commit 69e0cd33>.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Introduced by <commit 1bb1de83>.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The size argument accounts for the nul-byte to terminate
the string. Use sizeof and remove the pointless assignment.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Changing a parameter passed by value has no effect.

Introduced by <commit 3f74b2eb>.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Some instances of ARCH_IS_PPC64 did not use them.

Introduced by commits da636d83 and ef08a545Signed-off-by: NJán Tomko <jtomko@redhat.com>

Currently both virtlogd and virtlockd use a single worker thread for
dispatching RPC messages. Even this is overkill and their RPC message
handling callbacks all run in short, finite time and so blocking the
main loop is not an issue like you'd see in libvirtd with long running
QEMU commands.

By setting max_workers==0, we can turn off the worker thread and run
these daemons single threaded. This in turn fixes a serious problem in
the virtlockd daemon whereby it loses all fcntl() locks at re-exec due
to multiple threads existing. fcntl() locks only get preserved if the
process is single threaded at time of exec().
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

If max_workers is set to zero, then the worker thread pool won't be
created, so when serializing state for pre-exec we must set various
parameters to zero.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Currently if the virNetServer instance is created with max_workers==0 to
request a non-threaded dispatch process, we deadlock during dispatch

  #0  0x00007fb845f6f42d in __lll_lock_wait () from /lib64/libpthread.so.0
  #1  0x00007fb845f681d3 in pthread_mutex_lock () from /lib64/libpthread.so.0
  #2  0x000055a6628bb305 in virMutexLock (m=<optimized out>) at util/virthread.c:89
  #3  0x000055a6628a984b in virObjectLock (anyobj=<optimized out>) at util/virobject.c:435
  #4  0x000055a66286fcde in virNetServerClientIsAuthenticated (client=client@entry=0x55a663a7b960)
      at rpc/virnetserverclient.c:1565
  #5  0x000055a66286cc17 in virNetServerProgramDispatchCall (msg=0x55a663a7bc50, client=0x55a663a7b960,
      server=0x55a663a77550, prog=0x55a663a78020) at rpc/virnetserverprogram.c:407
  #6  virNetServerProgramDispatch (prog=prog@entry=0x55a663a78020, server=server@entry=0x55a663a77550,
      client=client@entry=0x55a663a7b960, msg=msg@entry=0x55a663a7bc50) at rpc/virnetserverprogram.c:307
  #7  0x000055a662871d56 in virNetServerProcessMsg (msg=0x55a663a7bc50, prog=0x55a663a78020, client=0x55a663a7b960,
      srv=0x55a663a77550) at rpc/virnetserver.c:148
  #8  virNetServerDispatchNewMessage (client=0x55a663a7b960, msg=0x55a663a7bc50, opaque=0x55a663a77550)
      at rpc/virnetserver.c:227
  #9  0x000055a66286e4c0 in virNetServerClientDispatchRead (client=client@entry=0x55a663a7b960)
      at rpc/virnetserverclient.c:1322
  #10 0x000055a66286e813 in virNetServerClientDispatchEvent (sock=<optimized out>, events=1, opaque=0x55a663a7b960)
      at rpc/virnetserverclient.c:1507
  #11 0x000055a662899be0 in virEventPollDispatchHandles (fds=0x55a663a7bdc0, nfds=<optimized out>)
      at util/vireventpoll.c:508
  #12 virEventPollRunOnce () at util/vireventpoll.c:657
  #13 0x000055a6628982f1 in virEventRunDefaultImpl () at util/virevent.c:327
  #14 0x000055a6628716d5 in virNetDaemonRun (dmn=0x55a663a771b0) at rpc/virnetdaemon.c:858
  #15 0x000055a662864c1d in main (argc=<optimized out>,
  #argv=0x7ffd105b4838) at logging/log_daemon.c:1235
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Currently virNetServerClientDispatchFunc implementations are only
responsible for free'ing the "msg" parameter upon success. Simplify the
calling convention by making it their unconditional responsibility to
free the "msg", and close the client if desired.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

There's no reason why the virNetServerClientDispatchRead method needs to
acquire an extra reference on the "client" object. An extra reference is
only needed if the registered dispatch callback is going to keep hold of
the "client" for work in the background. Thus we can push reference
acquisition into virNetServerDispatchNewMessage.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit ad84090b6f96.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This function was introduced in commit 41f5c2ca as a way
to probe the same property for multiple devices at once.

Although the resulting representation is very compact, it
doesn't provide any extra features compared to the existing
virQEMUCapsProcessStringFlags() mechanism, which is already
used for pretty much all device properties.

Drop the custom function and datatypes and start using the
standard ones instead.

Note that, in theory, the end result is not identical
because we're no longer probing properties for

  virtio-serial-pci
  virtio-9p-pci
  virtio-rng-pci
  virtio-input-host-pci
  virtio-keyboard-pci
  virtio-mouse-pci
  virtio-tablet-pci

However, chances of any of those devices being compiled
into a QEMU binary where

  virtio-balloon-pci
  virtio-blk-pci
  virtio-scsi-pci
  virtio-net-pci
  virtio-gpu-pci

are compiled out are slim enough that it doesn't make any
difference in practice, as the lack of test suite churn
shows.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

In some cases, we are probing multiple devices for the same
property and setting the corresponding capability if it's
found on any of the devices: when that happens, we can quit
early after finding the first property and avoiding a bunch
of string comparisons.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Commit 4ae59411 introduced the ability to make probing for
device properties conditional on a capability being set, but
didn't extend the use of this feature to existing devices.

This commit does the last bit of work, which results in a lot
of pointless QMP chatter no longer happening and our test suite
shrinking a fair bit.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

If we return -1 on VIR_ALLOC_N failure, we leaked @vms, so
goto cleanup instead.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove the rather bulky function in favor of an XPath query.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Pass in the XPath context as we do in all other places rather than
allocating a new one.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The function used the 'cleanup' label only in error cases. This patch
makes the code pass the cleanup label in every case and removes few
unnecessary VIR_FREEs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Remove the rather bulky function in favor of an XPath query.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Pass in the XPath context as we do in all other places rather than
allocating a new one.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Unify the cleanup and error paths and simplify the code flow by removing
some unnecessary variables.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

In certain cases a xml contains paths that do not yet exist, but
are valid as qemu will create them later on - for example
vhostuser mode=server sockets.

In any such cases so far the check to virFileExists failed and due to
that the paths stayed non-resolved in regard to symlinks.

But for apparmor those non-resolved rules are non functional as they
are evaluated after resolving any symlinks.

Therefore for non-existent files and partially non-existent paths
resolve as much as possible to get valid rules.

Example:
   <interface type='vhostuser'>
       <model type='virtio'/>
       <source type='unix' path='/var/run/symlinknet' mode='server'/>
   </interface>

Got rendered as:
  "/var/run/symlinknet" rw,

But correct with "/var/run" being a symlink to "/run" is:
  "/run/symlinknet" rw,
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

When commit 3545cbef moved the sysfs attribute reading logic from
_udev.c module to virmdev.c, it had to replace our udev read wrappers
with the ones available from virfile.c. The problem is that the original
logic worked correctly with udev read wrappers which don't return an
error code for a missing attribute, virfile.c readers however - not so
much. Therefore add another parameter to the macro, so we can again
accept the fact that optional attributes may be missing.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

If the user tries to define a domain that has

  <controller type='usb' model='none'/>

and also some USB devices, we report an error:
  error: internal error: No free USB ports

Which is technically still correct for a domain with no USB ports.

Change it to:

USB is disabled for this domain, but USB devices are present in the domain XML

https://bugzilla.redhat.com/show_bug.cgi?id=1347550Signed-off-by: NJán Tomko <jtomko@redhat.com>

When trying to destroy a domain (e.g. because we've seen EOF on
the monitor) we try to acquire QEMU_JOB_DESTROY. However, if
max_queued is set in qemu.conf this may fail and since our code
doesn't count on that we will still report domain as active even
though the qemu process is long gone. More specifically, if we've
seen EOF on the monitor, qemuProcessHandleMonitorEOF() is called
which sends MONITOR_EOF job to the event worker pool and
unregisters monitor from the event loop. The worker pool calls
processMonitorEOFEvent() which tries to set job which may fail
due to the limit as described above.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since QEMU 2.12 commit id '4ada99ade' guest crash information for
S390 is available in the QEMU monitor, e.g.:

  {
    "timestamp": {
        "seconds": 1518004739,
        "microseconds": 552563
    },
    "event": "GUEST_PANICKED",
    "data": {
        "action": "pause",
        "info": {
            "core": 0,
            "psw-addr": 1102832,
            "reason": "disabled-wait",
            "psw-mask": 562956395872256,
            "type": "s390"
        }
    }
  }

Let's log this information into the domain log file, e.g.:

    2018-02-08 13:11:26.075+0000: panic s390: core='0' psw-mask='0x0002000180000000' psw-addr='0x000000000010f146' reason='disabled-wait'
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Let us introduce the xml and reply files for QEMU 2.11.0 on s390x.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>