qemu: Add vhost-scsi string for -device parameter

Open /dev/vhost-scsi, and record the resulting file descriptor, so that
the guest has access to the host device outside of the libvirt daemon.
Pass this information, along with data parsed from the XML file, to build
a device string for the qemu command line.  That device string will be
for either a vhost-scsi-ccw device in the case of an s390 machine, or
vhost-scsi-pci for any others.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>

util: Management routines for scsi_host devices

For a new hostdev type='scsi_host' we have a number of
required functions for managing, adding, and removing the
host device to/from guests.  Provide the basic infrastructure
for these tasks.

The name "SCSIVHost" (and its variants) is chosen to avoid
conflicts with existing code named "SCSIHost" to refer to
a hostdev type='scsi' protcol='none'.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>

Introduce framework for a hostdev SCSI_host subsystem type

We already have a "scsi" hostdev subsys type, which refers to a single
LUN that is passed through to a guest.  But what of things where
multiple LUNs are passed through via a single SCSI HBA, such as with
the vhost-scsi target?  Create a new hostdev subsys type that will
carry this.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>

qemu: Introduce vhost-scsi capability

Do all the stuff for the vhost-scsi capability in QEMU,
so it's in place for our checks later.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>

tests: eventtest: fix build on macOS

macOS doesn't support clock_gettime(2), at least versions prior 10.12
(I didn't actually check 10.12 though). So, use its own routines in
eventtest.

 * configure.ac: check for requires symbols and define
   HAVE_MACH_CLOCK_ROUTINES if found
 * tests/eventtest.c: add clock_get_time() based implementation

tests: eventtest: fix LDADD

Don't explicitly LDADD -lrt, use $(LIB_CLOCK_GETTIME) because
not all platforms have clock_gettime(2) and librt available.

genprotocol.pl: add darwin to fixup list

vbox: get rid of g_pVBoxGlobalData

now that we have a new global vboxDriver object, remove the old
vboxGlobalData struct and all references to it.

vbox: change how vbox API is initialized.

* add vboxDriver object to serve as a singleton global object that
  holds references to IVirtualBox and ISession to be shared among
  multiple connections. The vbox_driver is instantiated only once in
  the first call vboxGetDriverConnection function that is guarded by
  a mutex.

* call vbox API initialize only when the first connection is
  established, and likewise uninitialize when last connection
  disconnects. The prevents each subsequent connection from overwriting
  IVirtualBox/ISession instances of any other active connection that
  led to libvirtd segfaults. The virConnectOpen and virConnectClose
  implementations are guarded by mutex on the global vbox_driver_lock
  where the global vbox_driver object counts connectios and decides
  when it's safe to call vbox's init/uninit routines.

* add IVirutalBoxClient to vboxDriver and use it to in tandem with newer
  pfnClientInitialize/pfnClientUninitalize APIs for vbox versions that
  support it, to avoid usage of the old pfnComInitialize/Uninitialize.

qemu: Removed an outdated comment in qemuDomainSaveImageStartVM()

Removed the comment 'Set the migration source' as it isn't valid anymore
and 'start it up' isn't useful as qemuProcessStart() is already a
speaking name.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>

virutil: fix trailing '/' for path prefixes

The path prefixes for sysfs trees are always prepended by paths
beginning with a slash, making the trailing slash in the prefix
redundant.

Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>

virfile: Only generate a warning if there is something to report

Only generate a warning if there is something to report.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Fix typos and grammar

Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>

qemu: Update cgroup on chardev hotplug

Just like in the previous commit, we are not updating CGroups on
chardev hot(un-)plug and thus leaving qemu unable to access any
non-default device users are trying to hotplug.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

qemu: Update cgroup on RNG hotplug

If users try to hotplug RNG device with a backend different to
/dev/random or /dev/urandom the whole operation fails as qemu is
unable to access the device. The problem is we don't update
device CGroups during the operation.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

docs: Add apps.html link to index.html

I think when trying to introduce libvirt (we have a section for
that in our index page) it might be useful to promote success
stories - other applications that are based on libvirt.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

NEWS: Close <li> tag properly

Not closing the <li> tag on a separate line causes the plain
text version of the file to have no empty line between entries.

NEWS: document the new libssh transport

qemu: agent: fix unsafe agent access

qemuDomainObjExitAgent is unsafe.

First it accesses domain object without domain lock.
Second it uses outdated logic that goes back to commit 79533da1 of
year 2009 when code was quite different. (unref function
instead of unreferencing only unlocked and disposed object
in case of last reference and leaved unlocking to the caller otherwise).
Nowadays this logic may lead to disposing locked object
i guess.

Another problem is that the callers of qemuDomainObjEnterAgent
use domain object again (namely priv->agent) without domain lock.

This patch address these two problems.

qemuDomainGetAgent is dropped as unused.

qemu: drop write-only agentStart

qemu: agent: cleanup agent error flag correctly

Sometimes after domain restart agent is unavailabe even
if it is up and running in guest. Diagnostic message is
"QEMU guest agent is not available due to an error"
that is 'priv->agentError' is set. Investiagion shows that
'priv->agent' is not NULL, so error flag is set probably
during domain shutdown process and not cleaned up eventually.

The patch is quite simple - just clean up error flag unconditionally
upon domain stop.

Other hunks address other cases when error flag is not cleaned up.

1. processSerialChangedEvent. We need to clean error flag
unconditionally here too. For example if upon first 'connected' event we
fail to connect and set error flag and then connect on second
'connected' event then error flag will remain set erroneously
and make agent unavailable.

2. qemuProcessHandleAgentEOF. If error flag is set and we get
EOF we need to change state (and diagnostic) from 'error' to
'not connected'.

qemu: agent: remove redundant check

qemu: agent: handle agent connection errors in one place

qemuConnectAgent return -1 or -2 in case of different errors.
A. -1 is a case of unsuccessuful connection to guest agent.
B. -2 is a case of destoyed domain during connection attempt.

All qemuConnectAgent callers handle the first error the same way
so let's move this logic into qemuConnectAgent itself. Patched
function returns 0 in case A and -1 in case B.

libvirtd: systemd: add special target for system shutdown

It is already discussed in "[RFC] daemon: remove hardcode dep on libvirt-guests" [1].

Mgmt can use means to save/restore domains on system shutdown/boot other than
libvirt-guests.service. Thus we need to specify appropriate ordering dependency between
libvirtd, domains and save/restore service. This patch takes approach suggested
in RFC and introduces a systemd target, so that ordering can be built next way:

libvirtd -> domain -> virt-guest-shutdown.target -> save-restore.service.

This way domains are decoupled from specific shutdown service via intermediate
target.

[1] https://www.redhat.com/archives/libvir-list/2016-September/msg01353.html

virsh: Document --rdma-pin-all migrate option properly

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

virsh: Add support for VIR_MIGRATE_PARAM_PERSIST_XML

Commit v1.3.3-181-gb028e9d7c implmented support for
VIR_MIGRATE_PARAM_PERSIST_XML migration parameter, but forgot to update
virsh.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Refactoring: Use virHostdevIsSCSIDevice()

Use the util function virHostdevIsSCSIDevice() to simplify if
statements.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>

util: Add virHostdevIsSCSIDevice()

Add the function virHostdevIsSCSIDevice() which detects whether a
hostdev is a SCSI device or not.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>

qemu: Fix improper union member access on hostdevs

Add missing checks if a hostdev is a subsystem/SCSI device before access
the union member 'subsys'/'scsi'.  Also fix indentation and simplify
qemuDomainObjCheckHostdevTaint().

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Forbid new-line char in name of new storagepool

New line character in name of storagepool is now forbidden because it
mess virsh output and can be confusing for users.
Validation of name is done in driver, after parsing XML to avoid
problems with dissappeared pools which was already created with
new-line char in name.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Forbid new-line char in name of new domain

New line character in name of domain is now forbidden because it
mess virsh output and can be confusing for users.
Validation of name is done in drivers, after parsing XML to avoid
problems with dissappeared domains which was already created with
new-line char in name.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

NEWS: Update entries

All of these changes have already been merged, so document
them properly.

NEWS: Update XSLT stylesheet

The new format requires some tweaks to be translated into
a nice plain text output, and the XSLT stylesheet needs to
be updated to match.

NEWS: Archive 2016 releases

We're going to change the format of the source HTML quite
a bit, and we're going to have to update the XSLT stylesheet
accordingly.

Move 2016 releases out of the way before doing so.

qemu: monitor: Properly propagate the 'qemu_id' field through the matcher

Commit 3f71c797689a4a70 added 'qemu_id' field to track the id of the cpu
as reported by query-cpus. The patch did not include changes necessary
to propagate the id through the functions matching the data to the
libvirt cpu structures and thus all vcpus had id 0.

tests: qemumonitorjson: Rename 'qemu-id' to 'enable-id' in cpu info test

The field is named 'enable_id' in other structures and a patch recently
added 'qemu_id' which has different semantics. To avoid confusion in the
tests rename the field.

bhyve: cleanup bhyveBuildNetArgStr error handling

Use 'goto cleanup'-style error handling instead of explicitly
freeing variables in every error path.

qemu: domain:  Refresh vcpu halted state using qemuMonitorGetCpuHalted

Don't use qemuMonitorGetCPUInfo which does a lot of matching to get the
full picture which is not necessary and would be mostly discarded.

Refresh only the vcpu halted state using data from query-cpus.

qemu: monitor: Extract halted state to a bitmap indexed by cpu id

We don't need to call qemuMonitorGetCPUInfo which is very inefficient to
get data required to update the vcpu 'halted' state.

Add a monitor helper that will retrieve the halted state and return it
in a bitmap so that it can be indexed easily.

qemu: monitor: Extract qemu cpu id along with other data

Storing of the ID will allow simpler extraction of data present only in
query-cpus without the need to call qemuMonitorGetCPUInfo in statistics
paths.

qemu_monitor_json: Don't check existence of "return" object

Whenever qemuMonitorJSONCheckError returns 0, the "return" object is
guaranteed to exist. Thus virJSONValueObjectGetObject will never fail to
get it. On the other hand, virJSONValueObjectGetArray may fail since the
"return" object may not be an array.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

NEWS: Start using the improved format

This entry is meant to both get the ball rolling on the
switch and to provide a blueprint of what NEWS file entries
are supposed to look like.

qemu: process: Set current vcpu count to maximum if it was not specified

Mimic qemu's behavior on the given command line.

qemu: parse: Assign maximum cpu count from topology if not provided

qemu uses this if 'maxcpus' is not present. Do the same in the parsing
code.

qemu: parse: Assign topology info earlier

Qemu can also use the topology to calculate the total vcpu count. To
allow parsing this move the assignment earlier.

qemu: parse: Allow the 'cpus=' prefix for current cpu number

qemu allows following syntax:

  -smp [cpus=]n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]

Allow the "cpus" prefix.

qemu: parse: Validate that the VM has at least one cpu

Libvirt's code relies on this fact so don't allow parsing a command line
which would have none.

Libvirtd would crash in the post parse callback on such config.

docs: Use Overpass Mono as the monospace font

Because this makes the font the same size as the non-monospaced one,
let's change those properties a little bit as well.  <pre/> will be
shrunk a bit and <code/> inside <p/> or <dd/> will have slightly greyer
background.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

docs: Add monospaced Overpass fonts

Overpass 3.0 has monospaced fonts, so why not have the same font for
the monospaced parts of the documentation.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

docs: Upgrade Overpass fonts to 3.0

Since we are using Overpass for the web pages, we might be using the
latest version.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

docs: Clean-up font definitions

Some of those were duplicate, so remove those.  In order to better see
such things in the future, sort them so they are "regular, italic,
bold, bold-italic, light, light-italic".

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Adapt to gluster_debug_level in qemu.conf

After a944bd92 we gained support for setting gluster debug level.
However, due to a space we haven't tested whether augeas file
actually works.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

util: Print pid_t as long long

After commit f2bf5fbb0449, MinGW strikes again.  Simply print pid as any
other place after commit b7d2d4af2bd5.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

configure: Look for daemons in **/sbin

Unify the logic we use for looking up daemons and admin binaries. Some
lookups prefered $PATH over **/sbin while others left out $PATH
entierly.  We add **/sbin since non-root users might not have these in
their path.

This also unbreaks libvirt when built on Debian systems with usrmerge[0]
and run on systems without it.

[0]: https://packages.debian.org/sid/usrmerge

Fix scheduler support check

Commit 94cc577807ba tried fixing build on systems that did not have
SCHED_BATCH or SCHED_IDLE defined.  But instead of changing it to
conditional support, it rather completely disabled the support for
setting any scheduler.  Since then, such old systems are not
supported, but rather than reverting that commit, let's change that to
the conditional support.  That way any addition to the list of
schedulers can follow the same style so that we're consistent in the
future.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

fs: Add proper switch to create filesystem with overwrite

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

When using the --overwrite switch on a pool-build or pool-create, the
The mkfs.ext{2|3|4} commands use mke2fs which requires using the '-F' switch
in order to force overwriting the current filesystem on the whole disk.

Likewise, the mkfs.vfat command uses mkfs.fat which requires using the '-I'
switch in order to force overwriting the current filesystem on the whole disk.

Avoid compiler warnings in virCPUDefStealModel

Old GCC on CentOS 6 thinks vendor and vendor_id might be used
uninitialized in virCPUDefStealModel. The compiler is wrong, though.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

build: update to latest gnulib

In particular, this is a quick gnulib fix for a mingw compile error.

* .gnulib: Update to latest.

Signed-off-by: Eric Blake <eblake@redhat.com>

bhyve: fix memory leaks in bhyvexml2argvtest

 * virNetDevTapCreateInBridgePort() mock: free '*ifname' before
   strdupping a hardoded value to it
 * testCompareXMLToArgvFiles(): unref 'conn' object in cleanup
 * testCompareXMLToArgvHelper(): free 'ldargs' and 'dmargs' in
   cleanup

docs: fix default value for sshauth option of libssh2/libssh

Both transports include "password" in their default authentication
methods.

spec: enable libssh transport on Fedora

remote: expose a new libssh transport

Implement in virtNetClient and VirNetSocket the needed functions to
expose a new libssh transport, providing all the options that the
libssh2 transport supports.

libssh_transport: add new libssh-based transport

Implement a new libssh transport, which uses libssh to communicate with
remote hosts, and add all the build system stuff (search of libssh,
private symbols, etc) to built it.

This new transport supports all the common ssh authentication methods,
making use of libvirt's auth callbacks for interaction with the user.

virnetsocket: improve search for default SSH key

Add a couple of helper functions to check whether one of the default
names of SSH keys (as documented in ssh-keygen(1)) exists, and use them
to specify a key for the libssh2 transport if none was passed.

virerror: add error for libssh transport

Add a new error domain and number for a new libssh-based transport.

virNetSocket: allow to not close FD

Add an internal variable to mark the FD as "not owned" by the
virNetSocket, in case the internal implementation takes the actual
ownership of the descriptor; this avoids a warning when closing the
socket, as the FD would be invalid.

cpu: Drop cpuGuestData

The API is not used anywhere in the code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Avoid adding <vendor> to custom CPUs

Guest CPU definitions with mode='custom' and missing <vendor> are
expected to run on a host CPU from any vendor as long as the required
CPU model can be used as a guest CPU on the host. But even though no CPU
vendor was explicitly requested we would sometimes force it due to a bug
in virCPUUpdate and virCPUTranslate.

The bug would effectively forbid cross vendor migrations even if they
were previously working just fine.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Introduce virCPUConvertLegacy API

PPC driver needs to convert POWERx_v* legacy CPU model names into POWERx
to maintain backward compatibility with existing domains. This patch
adds a new step into the guest CPU configuration work flow which CPU
drivers can use to convert legacy CPU definitions.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Don't test cpuGuestData

The API is no longer used anywhere else since it was replaced by a much
saner work flow utilizing new APIs that work on virCPUDefPtr directly:
virCPUCompare, virCPUUpdate, and virCPUTranslate.

Not testing the new work flow caused some bugs to be hidden. This patch
reveals them, but doesn't attempt to fix them. To make sure all test
still pass after this patch, all affected test results are modified to
pretend the tests succeeded. All of the bugs will be fixed in the
following commits and the artificial modifications will be reverted.

The following is the list of bugs in the new CPU model work flow:

- a guest CPU with mode='custom' and missing <vendor/> gets the vendor
  copied from host's CPU (the vendor should only be copied to host-model
  CPUs):
    DO_TEST_UPDATE("x86", "host", "min", VIR_CPU_COMPARE_IDENTICAL)
    DO_TEST_UPDATE("x86", "host", "pentium3", VIR_CPU_COMPARE_IDENTICAL)
    DO_TEST_GUESTCPU("x86", "host-better", "pentium3", NULL, 0)

- when a guest CPU with mode='custom' needs to be translated into
  another model because the original model is not supported by a
  hypervisor, the result will have its vendor set to the vendor of the
  original CPU model as specified in cpu_map.xml even if the original
  guest CPU XML didn't contain <vendor/>:
    DO_TEST_GUESTCPU("x86", "host", "guest", model486, 0)
    DO_TEST_GUESTCPU("x86", "host", "guest", models, 0)
    DO_TEST_GUESTCPU("x86", "host-Haswell-noTSX", "Haswell-noTSX",
                     haswell, 0)

- legacy POWERx_v* model names are not recognized:
    DO_TEST_GUESTCPU("ppc64", "host", "guest-legacy", ppc_models, 0)

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Make models array in virCPUTranslate constant

The API doesn't change the array so let's make it constant.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Don't use preferred CPU model at all

Now that all tests pass NULL as the preferred model, we can just drop
that test parameter.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Don't use superfluous preferred model

In some cases preferred model doesn't really do anything since the
result remains the same even if it is removed.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Don't use preferred model with forbidden fallback

Using a preferred model for guest CPUs with forbidden fallback masks a
bug in the code. It would just happily use another CPU model supported
by a hypervisor even though it is explicitly forbidden in the CPU XML.

This patch temporarily changes the expected result to -2, which is used
when the result XML file cannot be found (but it was supposed not to be
found since the tested API should have failed). The result will be
switched back to -1 few commits later when the original bug gets fixed.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Don't use unsupported preferred model

Using a preferred CPU model which is not in the list of CPU models
supported by a hypervisor does not make sense.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Don't use preferred model for minimum match CPUs

Guest CPUs with match='minimum' should always be updated to match host
CPU model. Trying to get different results by supplying preferred models
does not make sense.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Rename cpuDataFormat

The new name is virCPUDataFormat.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Rename cpuDataParse

The new name is virCPUDataParse.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Rename and document cpuModelIsAllowed

The new name is virCPUModelIsAllowed.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Rename cpuGetModels

The new name is virCPUGetModels.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

qemu: fix libvirtd crash when querying halted cpus info

It was introduced by commit 7a51d9ebb, which started to use
monitor commands without job acquiring, which is unsafe and leads
to simultaneous access to vm->mon structure by different threads.

Crash backtrace is the following (shortened):

Program received signal SIGSEGV, Segmentation fault.
qemuMonitorSend (mon=mon@entry=0x7f4ef4000d20, msg=msg@entry=0x7f4f18e78640) at qemu/qemu_monitor.c:1011
1011        while (!mon->msg->finished) {

0  qemuMonitorSend () at qemu/qemu_monitor.c:1011
1  0x00007f691abdc720 in qemuMonitorJSONCommandWithFd () at qemu/qemu_monitor_json.c:298
2  0x00007f691abde64a in qemuMonitorJSONCommand at qemu/qemu_monitor_json.c:328
3  qemuMonitorJSONQueryCPUs at qemu/qemu_monitor_json.c:1408
4  0x00007f691abcaebd in qemuMonitorGetCPUInfo g@entry=false) at qemu/qemu_monitor.c:1931
5  0x00007f691ab96863 in qemuDomainRefreshVcpuHalted at qemu/qemu_domain.c:6309
6  0x00007f691ac0af99 in qemuDomainGetStatsVcpu at qemu/qemu_driver.c:18945
7  0x00007f691abef921 in qemuDomainGetStats  at qemu/qemu_driver.c:19469
8  qemuConnectGetAllDomainStats at qemu/qemu_driver.c:19559
9  0x00007f693382e806 in virConnectGetAllDomainStats at libvirt-domain.c:11546
10 0x00007f6934470c40 in remoteDispatchConnectGetAllDomainStats at remote.c:6267

(gdb) p mon->msg
$1 = (qemuMonitorMessagePtr) 0x0

This change fixes it by calling qemuDomainRefreshVcpuHalted only when job is acquired.

Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>

qemu: initially reserve one open pcie-root-port for hotplug

For machinetypes with a pci-root bus (all legacy PCI), libvirt will
make a "fake" reservation for one extra slot prior to assigning
addresses to unaddressed PCI endpoint devices in the domain. This will
trigger auto-adding of a pci-bridge for the final device to be
assigned an address *if that device would have otherwise instead been
the last device on the last available pci-bridge*; thus it assures
that there will always be at least one slot left open in the domain's
bus topology for expansion (which is important both for hotplug (since
a new pci-bridge can't be added while the guest is running) as well as
for offline additions to the config (since adding a new device might
otherwise in some cases require re-addressing existing devices, which
we want to avoid)).

It's important to note that for the above case (legacy PCI), we must
check for the special case of all slots on all buses being occupied
*prior to assigning any addresses*, and avoid attempting to reserve
the extra address in that case, because there is no free address in
the existing topology, so no place to auto-add a pci-bridge for
expansion (i.e. it would always fail anyway). Since that condition can
only be reached by manual intervention, this is acceptable.

For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's
methodology for automatically expanding the bus topology is different
- pcie-root-ports are plugged into slots (soon to be functions) of
pcie-root as needed, and the new endpoint devices are assigned to the
single slot in each pcie-root-port. This is done so that the devices
are, by default, hotpluggable (the slots of pcie-root don't support
hotplug, but the single slot of the pcie-root-port does). Since
pcie-root-ports can only be plugged into pcie-root, and we don't
auto-assign endpoint devices to the pcie-root slots, this means
topology expansion doesn't compete with endpoint devices for slots, so
we don't need to worry about checking for all "useful" slots being
free *prior* to assigning addresses to new endpoint devices - as a
matter of fact, if we attempt to reserve the open slots before the
used slots, it can lead to errors.

Instead this patch just reserves one slot for a "future potential"
PCIe device after doing the assignment for actual devices, but only
if the only PCI controller defined prior to starting address
assignment was pcie-root, and only if we auto-added at least one PCI
controller during address assignment. This assures two things:

1) that reserving the open slots will only be done when the domain is
   initially defined, never at any time after, and

2) that if the user understands enough about PCI controllers that they
   are adding them manually, that we don't mess up their plan by
   adding extras - if they know enough to add one pcie-root-port, or
   to manually assign addresses such that no pcie-root-ports are
   needed, they know enough to add extra pcie-root-ports if they want
   them (this could be called the "libguestfs clause", since
   libguestfs needs to be able to create domains with as few
   devices/controllers as possible).

This is set to reserve a single free port for now, but could be
increased in the future if public sentiment goes in that direction
(it's easy to increase later, but essentially impossible to decrease)

qemu: try to put ich9 sound device at 00:1B.0

Real Q35 hardware has an ICH9 chip that includes several integrated
devices at particular addresses (see the file docs/q35-chipset.cfg in
the qemu source). libvirt already attempts to put the first two sets
of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the
real hardware. This patch does the same for the ich9 "HD audio"
device.

The main inspiration for this patch is that currently the *only*
device in a reasonable "workstation" type virtual machine config that
requires a legacy PCI slot is the audio device, Without this patch,
the standard Q35 machine created by virt-manager will have a
dmi-to-pci-bridge and a pci-bridge just for the sound device; with the
patch (and if you change the sound device model from the default
"ich6" to "ich9"), the machine definition constructed by virt-manager
has absolutely no legacy PCI controllers - any legacy PCI devices
(e.g. video and sound) are on pcie-root as integrated devices.

qemu: add a USB3 controller to Q35 domains by default

Previously we added a set of EHCI+UHCI controllers to Q35 machines to
mimic real hardware as closely as possible, but recent discussions
have pointed out that the nec-usb-xhci (USB3) controller is much more
virtualization-friendly (uses less CPU), so this patch switches the
default for Q35 machinetypes to add an XHCI instead (if it's
supported, which it of course *will* be).

Since none of the existing test cases left out USB controllers in the
input XML, a new Q35 test case was added which has *no* devices, so
ends up with only the defaults always put in by qemu, plus those added
by libvirt.

qemu: don't force-add a dmi-to-pci-bridge just on principle

Now the a dmi-to-pci-bridge is automatically added just as it's needed
(when a pci-bridge is being added), we no longer have any need to
force-add one to every single Q35 domain.

qemu: update tests to not assume dmi-to-pci-bridge is always added

A few of the qemu test cases assume that a dmi-to-pci-bridge will
always be added at index 1, and so they omit it from the input data
even though a pci-bridge is present at index 2, e.g.:

   <controller type='pci' index='0' model='pcie-root'/>
   <controller type='pci' index='2' model='pci-bridge'/>

Support for this odd practice was discussed on libvir-list and we
decided that the complex code required to make this continue was not
worth the headache of maintaining. So instead, this patch modifies the
test cases to manually add a dmi-to-pci-bridge at index 1 (since an
upcoming patch is going to eliminate the unconditional adding of
dmi-to-pci-bridge).

Because the auto-add was placing the dmi-to-pci-bridge later in the
list (even though it has a lower index) the test output is also
updated to take account for the new order (which puts the pci
controllers in index-order)

qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

Previously libvirt would only add pci-bridge devices automatically
when an address was requested for a device that required a legacy PCI
slot and none was available. This patch expands that support to
dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a
machine with a pcie-root), and pcie-root-port (which is needed to add
a hotpluggable PCIe device). It does *not* automatically add
pcie-switch-upstream-ports or pcie-switch-downstream-ports (and
currently there are no plans for that).

Given the existing code to auto-add pci-bridge devices, automatically
adding pcie-root-ports is fairly straightforward. The
dmi-to-pci-bridge support is a bit tricky though, for a few reasons:

1) Although the only reason to add a dmi-to-pci-bridge is so that
   there is a reasonable place to plug in a pci-bridge controller,
   most of the time it's not the presence of a pci-bridge *in the
   config* that triggers the requirement to add a dmi-to-pci-bridge.
   Rather, it is the presence of a legacy-PCI device in the config,
   which triggers auto-add of a pci-bridge, which triggers auto-add of
   a dmi-to-pci-bridge (this is handled in
   virDomainPCIAddressSetGrow() - if there's a request to add a
   pci-bridge we'll check if there is a suitable bus to plug it into;
   if not, we first add a dmi-to-pci-bridge).

2) Once there is already a single dmi-to-pci-bridge on the system,
   there won't be a need for any more, even if it's full, as long as
   there is a pci-bridge with an open slot - you can also plug
   pci-bridges into existing pci-bridges. So we have to make sure we
   don't add a dmi-to-pci-bridge unless there aren't any
   dmi-to-pci-bridges *or* any pci-bridges.

3) Although it is strongly discouraged, it is legal for a pci-bridge
   to be directly plugged into pcie-root, and we don't want to
   auto-add a dmi-to-pci-bridge if there is already a pci-bridge
   that's been forced directly into pcie-root.

Although libvirt will now automatically create a dmi-to-pci-bridge
when it's needed, the code still remains for now that forces a
dmi-to-pci-bridge on all domains with pcie-root (in
qemuDomainDefAddDefaultDevices()). That will be removed in a future
patch.

For now, the pcie-root-ports are added one to a slot, which is a bit
wasteful and means it will fail after 31 total PCIe devices (30 if
there are also some PCI devices), but helps keep the changeset down
for this patch. A future patch will have 8 pcie-root-ports sharing the
functions on a single slot.

qemu: only force an available legacy-PCI slot on domains with pci-root

Andrea had the right idea when he disabled the "reserve an extra
unused slot" bit for aarch64/virt. For *any* PCI Express-based
machine, it is pointless since 1) an extra legacy-PCI slot can't be
used for hotplug, since hotplug into legacy PCI slots doesn't work on
PCI Express machinetypes, and 2) even for "coldplug" expansion,
everybody will want to expand using Express controllers, not legacy
PCI.

This patch eliminates the extra slot reserve unless the system has a
pci-root (i.e. legacy PCI)

qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate

The nec-usb-xhci device (which is a USB3 controller) has always
presented itself as a PCI device when plugged into a legacy PCI slot,
and a PCIe device when plugged into a PCIe slot, but libvirt has
always auto-assigned it to a legacy PCI slot.

This patch changes that behavior to auto-assign to a PCIe slot on
systems that have pcie-root (e.g. Q35 and aarch64/virt).

Since we don't yet auto-create pcie-*-port controllers on demand, this
means a config with an nec-xhci USB controller that has no PCI address
assigned will also need to have an otherwise-unused pcie-*-port
controller specified:

   <controller type='pci' model='pcie-root-port'/>
   <controller type='usb' model='nec-xhci'/>

(this assumes there is an otherwise-unused slot on pcie-root to accept
the pcie-root-port)

qemu: assign e1000e network devices to PCIe slots when appropriate

The e1000e is an emulated network device based on the Intel 82574,
present in qemu 2.7.0 and later. Among other differences from the
e1000, it presents itself as a PCIe device rather than legacy PCI. In
order to get it assigned to a PCIe controller, this patch updates the
flags setting for network devices when the model name is "e1000e".

(Note that for some reason libvirt has never validated the network
device model names other than to check that there are no dangerous
characters in them. That should probably change, but is the subject of
another patch.)

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

qemu: assign virtio devices to PCIe slot when appropriate

libvirt previously assigned nearly all devices to a "hotpluggable"
legacy PCI slot even on machines with a PCIe root bus (and even though
most such machines don't even support hotplug on legacy PCI slots!)
Forcing all devices onto legacy PCI slots means that the domain will
need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a
pci-bridge (to provide hotpluggable legacy PCI slots which, again,
usually aren't hotpluggable anyway).

To help reduce the need for these legacy controllers, this patch tries
to assign virtio-1.0-capable devices to PCIe slots whenever possible,
by setting appropriate connectFlags in
virDomainCalculateDevicePCIConnectFlags(). Happily, when that function
was written (just a few commits ago) it was created with a
"virtioFlags" argument, set by both of its callers, which is the
proper connectFlags to set for any virtio-*-pci device - depending on
the arch/machinetype of the domain, and whether or not the qemu binary
supports virtio-1.0, that flag will have either been set to PCI or
PCIe. This patch merely enables the functionality by setting the flags
for the device to whatever is in virtioFlags if the device is a
virtio-*-pci device.

NB: the first virtio video device will be placed directly on bus 0
slot 1 rather than on a pcie-root-port due to the override for primary
video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not
to change that is a topic of discussion, but this patch doesn't change
that particular behavior.

NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root
complex) does *not* support hotplug, this means that suitable
controllers must also be in the config (i.e. either pcie-root-port, or
pcie-downstream-port). For now, libvirt doesn't add those
automatically, so if you put virtio devices in a config for a qemu
that has PCIe-capable virtio devices, you'll need to add extra
pcie-root-ports yourself. That requirement will be eliminated in a
future patch, but for now, it's simple to do this:

   <controller type='pci' model='pcie-root-port'/>
   <controller type='pci' model='pcie-root-port'/>
   <controller type='pci' model='pcie-root-port'/>
   ...

Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024

qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device isn't PCI

This patch cleans up the connect flags for certain types/models of
devices that aren't PCI to return 0. In the future that may be used as
an indicator to the caller about whether or not a device needs a PCI
address. For now it's just ignored, except for in
virDomainPCIAddressEnsureAddr() - called during device hotplug - (and
in some cases actually needs to be re-set to PCI|HOTPLUGGABLE just in
case someone (in some old config) has manually set a PCI address for a
device that isn't PCI.

qemu: set/use proper pciConnectFlags during hotplug

Before now, all the qemu hotplug functions assumed that all devices to
be hotplugged were legacy PCI endpoint devices
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
devices *are* legacy PCI endpoint devices on x86/440fx machinetypes,
and hotplug didn't work properly on machinetypes using PCIe anyway
(hotplugging onto a legacy PCI slot doesn't work, and until commit
b87703cf any attempt to manually specify a PCIe address for a
hotplugged device would be erroneously rejected).

This patch makes all qemu hotplug operations honor the pciConnectFlags
set by the single all-knowing function
qemuDomainDeviceCalculatePCIConnectFlags(). This is done in 3 steps,
but in a single commit since we would have to touch the other points
at each step anyway:

1) add a flags argument to the hypervisor-agnostic
virDomainPCIAddressEnsureAddr() (previously it hardcoded
..._PCI_DEVICE)

2) add a new qemu-specific function qemuDomainEnsurePCIAddress() which
gets the correct pciConnectFlags for the device from
qemuDomainDeviceConnectFlags(), then calls
virDomainPCIAddressEnsureAddr().

3) in qemu_hotplug.c replace all calls to
virDomainPCIAddressEnsureAddr() with calls to
qemuDomainEnsurePCIAddress()

So in effect, we're putting a "shim" on top of all calls to
virDomainPCIAddressEnsureAddr() that sets the right pciConnectFlags.

qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses

Set pciConnectFlags in each device's DeviceInfo and then use those
flags later when validating existing addresses in
qemuDomainCollectPCIAddress() and when assigning new addresses with
qemuDomainPCIAddressReserveNextAddr() (rather than scattering the
logic about which devices need which type of slot all over the place).

Note that the exact flags set by
qemuDomainDeviceCalculatePCIConnectFlags() are different from the
flags previously set manually in qemuDomainCollectPCIAddress(), but
this doesn't matter because all validation of addresses in that case
ignores the setting of the HOTPLUGGABLE flag, and treats PCIE_DEVICE
and PCI_DEVICE the same (this lax checking was done on purpose,
because there are some things that we want to allow the user to
specify manually, e.g. assigning a PCIe device to a PCI slot, that we
*don't* ever want libvirt to do automatically. The flag settings that
we *really* want to match are 1) the old flag settings in
qemuDomainAssignDevicePCISlots() (which is HOTPLUGGABLE | PCI_DEVICE
for everything except PCI controllers) and 2) the new flag settings
done by qemuDomainDeviceCalculatePCIConnectFlags() (which are
currently exactly that - HOTPLUGGABLE | PCI_DEVICE for everything
except PCI controllers).

qemu: new functions to calculate/set device pciConnectFlags

The lowest level function of this trio
(qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single
authority for the virDomainPCIConnectFlags to use for any given device
using a particular arch/machinetype/qemu-binary.

qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a
single device (unless it has no virDomainDeviceInfo, in which case
it's a NOP).

qemuDomainFillAllPCIConnectFlags() sets info->pciConnectFlags in all
devices that have a virDomainDeviceInfo

The latter two functions aren't called anywhere yet. This commit is
just making them available. Later patches will replace all the current
hodge-podge of flag settings with calls to this single authority.

qemu: new functions qemuDomainMachineHasPCI[e]Root()

These functions provide a simple one line method of learning if the
current domain has a pci-root or pcie-root bus.

vz: fixed migration in p2p mode

dom xml generated on begin step should be passed
to perform step in VIR_MIGRATE_PARAM_DEST_XML parameter.
Otherwise 'XML error: failed to parse xml document' is
raised on destination host as dom xml is NULL.

Signed-off-by: Pavel Glushchak <pglushchak@virtuozzo.com>

tools: Replace vshPrint with vshPrintExtra on places we forgot about

Although there already was an effort (b620bdee) to replace vshPrint occurrences
with vshPrintExtra due to '--quiet' flag, there were still some leftovers. So
this patch fixes them, hopefully for good.

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

Signed-off-by: Erik Skultety <eskultet@redhat.com>

tools: use vshError rather than vshPrint on failure

There were a few places in our virsh* code where instead of calling vshError
on failure we called vshPrint.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

storage.html.in: Kill useless spaces in <pre/>

The <pre/> section is rendered as-is on the page. That is, if all
the lines are prefixed with 4 spaces the rendered page will also
have them. Problem is if we put a box around such <pre/> because
the content might not fix into it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>