Similarly to devices the guest may allow unplug of the VCPU if libvirt
is down. To avoid problems, refresh the vcpu state on reconnect. Don't
mess with the vcpu state otherwise.

Now that the monitor code gathers all the data we can extract it to
relevant places either in the definition or the private data of a vcpu.

As only thread id is broken for TCG guests we may extract the rest of
the data and just skip assigning of the thread id. In case where qemu
would allow cpu hotplug in TCG mode this will make it work eventually.

For hotplug purposes it's necessary to retrieve data using
query-hotpluggable-cpus while the old query-cpus API report thread IDs
and order of hotplug.

This patch adds code that merges the data using a rather non-trivial
algorithm and fills the data to the qemuMonitorCPUInfo structure for
adding to appropriate place in the domain definition.

Add support for retrieving information regarding hotpluggable cpu units
supported by qemu. Data returned by the command carries information
needed to figure out the granularity of hotplug, the necessary cpu type
name and the topology information.

Note that qemu doesn't specify any particular order of the entries thus
it's necessary sort them by socket_id, core_id and thread_id to the
order libvirt expects.

To allow matching up the data returned by query-cpus to entries in the
query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract
the QOM path as it's the only link between the two.

QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
machine type. Extract and cache the information using the capability
cache.

When copying the capabilities for a new start of qemu, mask out the
presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
doesn't support hotpluggable cpus.

As of qemu commit:
commit a32ef3bfc12c8d0588f43f74dcc5280885bbdb30
Author: Thomas Huth <thuth@redhat.com>
Date:   Wed Jul 22 15:59:50 2015 +0200

    vl: Add another sanity check to smp_parse() function

v2.4.0-952-ga32ef3b

configuration where the maximum CPU count doesn't match the topology is
rejected. Prior to that only configurations where the topology would
contain more cpus than the maximum count would be rejected.

Use QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS as a relevant recent enough
witness to avoid breaking old configs.

Prepare to extract more data by returning an array of structs rather than
just an array of thread ids. Additionally report fatal errors separately
from qemu not being able to produce data.

The function will gradually add more returned data. Return a struct for
every vCPU containing the data.

remove the dead code this patch is to remove the dead code Signed-off-by: JieWang <wangjie88@huawei.com>
Signed-off-by: NJieWang <wangjie88@huawei.com>

Check whether the disable-legacy property is present on the following
devices:
  virtio-balloon-pci
  virtio-blk-pci
  virtio-scsi-pci
  virtio-serial-pci
  virtio-9p-pci
  virtio-net-pci
  virtio-rng-pci
  virtio-gpu-pci
  virtio-input-host-pci
  virtio-keyboard-pci
  virtio-mouse-pci
  virtio-tablet-pci

Assuming that if QEMU knows other virtio devices where this property
is applicable, it will have at least one of these devices.

Added in QEMU by:
commit e266d421490e0ae83044bbebb209b2d3650c0ba6
    virtio-pci: add flags to enable/disable legacy/modern

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

Since libvirt still uses a legacy qemu arg format to add a disk, the
manner in which the 'password-secret' argument is passed to qemu needs
to change to prepend a 'file.' If in the future, usage of the more
modern disk format, then the prepended 'file.' can be removed.

Fix based on Jim Fehlig <jfehlig@suse.com> posting and subsequent
upstream list followups, see:

http://www.redhat.com/archives/libvir-list/2016-August/msg00777.html

for details. Introduced by commit id 'a1344f70'.

s/libvirt.c/libvirt-domain.c
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

The code that setups listen types may change a listen type from address to
socket based on configuration from qemu.conf.  This needs to be done before we
reserve/allocate ports that won't be used.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1364843Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Ports are valid only for listen types 'address' and 'network', other listen
types doesn't use them so we should not try to reserve any ports.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: Pavel Hrdina <phrdina@redhat.com

The first argument should be const char ** instead of
char **, because this is a search function and as such it
doesn't, and shouldn't, alter the haystack in any way.

This change means we no longer have to cast arrays of
immutable strings to arrays of mutable strings; we still
have to do the opposite, though, but that's reasonable.

All other modes of qemuDomainSetVcpusFlags have helpers so finish the
work by splitting the regular code into a new function.

This patch also touches up the coding (spacing) style.

The live code does ugly things. Contain it in a separate function.

Setting of the maximum vcpu count is slightly semantically different
thus split it into a self-contained func.

Mention whether it was the live or persistent definition which caused an
error reported and explicitly error out in case when attempting to set
maximum vcpu count for a live domain.

Setting heads to 0 in case that *max_outputs* is not supported while building
command line doesn't have any real effect.  It only removes *heads* attribute
from live XML, but after restarting libvirt the default value is restored.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Since we now pick the default USB controller model when parsing
the guest XML, we can get rid of some duplicated code so that
the default model selection happens in one place only.

Add some comments as well.

Now that the default USB controller model is explicit rather
than implicit for i440fx machines, we have to tweak the
conditions for dropping it in order to keep migration towards
libvirt <= 0.9.4 working.

When the user doesn't specify any model for a USB controller,
we use an architecture-dependent default, but we don't reflect
it in the guest XML.

Pick the default USB controller model when parsing the guest
XML instead of when creating the QEMU command line, so that
our choice is saved back to disk.

Since a9331394 (first release v2.1.0), specifying a manual
security_driver setting in qemu.conf causes the daemon to fail to
start, erroring with 'Duplicate security driver X'.

The duplicate checking was incorrectly comparing every entry
against itself, guaranteeing a false positive.

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

Doing a load, copy, format cycle on all QEMU capabilities XML files
should make sure we don't forget to update virQEMUCapsNewCopy when
adding new elements to QEMU capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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

Commit id 'f522b7d2' caused a build failure :

GEN      check-augeas-virtlogd
Test failure:test_libvirtd_qemu.aug:69.3-147.28:
 Expected:
{
...
  { "nvram"
    { "1" = "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" }
    { "2" = "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd" }
  }
...
 Actual:
...
{
  { "nvram"
    { "1" = "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" }
    { "2" = "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd" }
    { "3" = "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd" }
  }
...

This patch adds the OVMF_CODE.secboot.fd to the aug.in file
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

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

In qemu, enabling this feature boils down to adding the following
onto the command line:

  -global driver=cfi.pflash01,property=secure,value=on

However, there are some constraints resulting from the
implementation. For instance, System Management Mode (SMM) is
required to be enabled, the machine type must be q35-2.4 or
later, and the guest should be x86_64. While technically it is
possible to have 32 bit guests with secure boot, some non-trivial
CPU flags tuning is required (for instance lm and nx flags must
be prohibited). Given complexity of our CPU driver, this is not
trivial. Therefore I've chosen to forbid 32 bit guests for now.
If there's ever need, we can refine the check later.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We use 'goto cleanup' for a reason. If a function can exit at
many places but doesn't follow the pattern, it has to copy the
free code in multiple places.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Call the vcpu thread info validation separately to decrease complexity
of returned values by qemuDomainRefreshVcpuInfo.

This function now returns 0 on success and -1 on error. Certain
failures of qemu to report data are still considered as success. Any
error reported now is fatal.