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

Just like virDomainDefPostParseCallback has gained new
parseOpaque argument, we need to follow the logic with
virDomainDeviceDefPostParse.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseString.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseXML and subsequently virDomainDefPostParse too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want to see different data (e.g. domain object pointer that
domain def belongs to).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

The domain capabilities XML is capable of showing whether each guest CPU
mode is supported or not with a possibility to provide additional
details. This patch enhances host-model capability to advertise the
exact CPU model which will be used as a host-model:

    <cpu>
        ...
        <mode name='host-model' supported='yes'>
            <model fallback='allow'>Broadwell</model>
            <vendor>Intel</vendor>
            <feature policy='disable' name='aes'/>
            <feature policy='require' name='vmx'/>
        </mode>
        ...
    </cpu>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function filters all CPU features through a given callback while
copying CPU model related parts of a CPU definition.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function moves CPU model related parts from one CPU definition to
another. It can be used to avoid unnecessary copies from a temporary CPU
definitions which will be freed anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Useful for copying a CPU definition without model related parts (i.e.,
without model name, feature list, vendor).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In case a hypervisor is able to tell us a list of supported CPU models
and whether each CPU models can be used on the current host, we can
propagate this to domain capabilities. This is a better alternative
to calling virConnectCompareCPU for each supported CPU model.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Listing all CPU models supported by QEMU in domain capabilities makes
little sense when libvirt will refuse any model it doesn't know about.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The patch adds <cpu> element to domain capabilities XML:

    <cpu>
        <mode name='host-passthrough' supported='yes'/>
        <mode name='host-model' supported='yes'/>
        <mode name='custom' supported='yes'>
            <model>Broadwell</model>
            <model>Broadwell-noTSX</model>
            ...
        </mode>
    </cpu>

Applications can use it to inspect what CPU configuration modes are
supported for a specific combination of domain type, emulator binary,
guest architecture and machine type.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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

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

Return whether the live or persistent definition was returned. Sometimes
it's necessary to base the decisions on this.

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

This way we'll be able to hotplug with both --live and --config in one
API call.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In a full domain config, libvirt allows overriding the normal PCI
vs. PCI Express rules when a device address is explicitly provided
(so, e.g., you can force a legacy PCI device to plug into a PCIe port,
although libvirt would never do that on its own). However, due to a
bug libvirt doesn't give this same leeway when hotplugging devices. On
top of that, current libvirt assumes that *all* devices are legacy
PCI. The result of all this is that it's impossible to hotplug a
device into a PCIe port, even if you manually add the PCI address.

This can all be traced to the function
virDomainPCIAddressEnsureAddr(), and the fact that it calls
virDomainPCIaddressReserveSlot() for manually set addresses, and that
function hardcodes the argument "fromConfig" to false (meaning "this
address was auto-assigned, so it should be subject to stricter
validation").

Since virDomainPCIAddressReserveSlot() is just a one line simple
wrapper around virDomainPCIAddressReserveAddr() (adding in a hardcoded
reserveEntireSlot = true and fromConfig = false), all that's needed to
solve the problem with no unwanted side effects is to replace that
call for virDomainPCIAddressReserveSlot() with a direct call to
virDomainPCIAddressReserveAddr(), but with reserveEntireSlot = true,
fromConfig = true. That's what this patch does.

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

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1218603Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

QEMU added another virtio-net tunable [1]. It basically allows
users to set the size of RX virtio ring. But because virtio-net
uses two separate ring buffers to pass data from/to guest they
named it explicitly rx_queue_size. We should expose it in our XML
too.

1: http://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg02029.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new secret usage type known as "tls" - it will handle adding the
secret objects for various TLS objects that need to provide some sort
of passphrase in order to access the credentials.

The format is:

   <secret ephemeral='no' private='no'>
     <description>Sample TLS secret</description>
     <usage type='tls'>
       <name>mumblyfratz</name>
     </usage>
</secret>

Once defined and a passphrase set, future patches will allow the UUID
to be set in the qemu.conf file and thus used as a secret for various
TLS options such as a chardev serial TCP connection, a NBD client/server
connection, and migration.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If the incoming XML defined a path to a TLS X.509 certificate environment,
add the necessary 'tls-creds-x509' object to the VIR_DOMAIN_CHR_TYPE_TCP
character device.

Likewise, if the environment exists the hot unplug needs adjustment as
well.  Note that all the return ret were changed to goto cleanup since
the cfg needs to be unref'd
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The code for replacing domain's transient definition with the persistent
one is repeated in several places and we'll need to add one more. Let's
make a nice helper for it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In the latest glibc, major() and minor() functions are marked as
deprecated (glibc commit dbab6577):

  CC       util/libvirt_util_la-vircgroup.lo
util/vircgroup.c: In function 'virCgroupGetBlockDevString':
util/vircgroup.c:768:5: error: '__major_from_sys_types' is deprecated:
  In the GNU C Library, `major' is defined by <sys/sysmacros.h>.
  For historical compatibility, it is currently defined by
  <sys/types.h> as well, but we plan to remove this soon.
  To use `major', include <sys/sysmacros.h> directly.
  If you did not intend to use a system-defined macro `major',
  you should #undef it after including <sys/types.h>.
  [-Werror=deprecated-declarations]
     if (virAsprintf(&ret, "%d:%d ", major(sb.st_rdev), minor(sb.st_rdev)) < 0)
     ^~
In file included from /usr/include/features.h:397:0,
                 from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdio.h:28,
                 from ../gnulib/lib/stdio.h:43,
                 from util/vircgroup.c:26:
/usr/include/sys/sysmacros.h:87:1: note: declared here
 __SYSMACROS_DEFINE_MAJOR (__SYSMACROS_FST_IMPL_TEMPL)
 ^

Moreover, in the glibc commit, there's suggestion to keep
ordering of including of header files as implemented here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since the domain lock is not held during preparation of an external XML
config, it is possible that the value can change resulting in unexpected
failures during ABI consistency checking for some save and migrate
operations.

This patch adds a new flag to skip the checking of the cur_balloon value
and then sets the destination value to the source value to ensure
subsequent checks without the skip flag will succeed.

This way it is protected from forges and is keeped up to date too.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

The 'multi' element in PCI address struct used as 'virTristateSwitch',
and its default value is 'VIR_TRISTATE_SWITCH_ABSENT'. Current PCI
process use 'false' to initialization 'multi', which is ambiguously
for assignment or comparison. This patch use '{0}' to initialize
the whole PCI address struct, which fix the 'multi' initialization
and makes code more simplify and explicitly.
Signed-off-by: NXian Han Yu <xhyubj@linux.vnet.ibm.com>

Test 12 from objecteventtest (createXML add event) segaults on FreeBSD
with bus error.

At some point it calls testNodeDeviceDestroy() from the test driver. And
it fails when it tries to unlock the device in the "out:" label of this
function.

Unlocking fails because the previous step was a call to
virNodeDeviceObjRemove from conf/node_device_conf.c. This function
removes the given device from the device list and cleans up the object,
including destroying of its mutex. However, it does not nullify the pointer
that was given to it.

As a result, we end up in testNodeDeviceDestroy() here:

 out:
    if (obj)
        virNodeDeviceObjUnlock(obj);

And instead of skipping this, we try to do Unlock and fail because of
malformed mutex.

Change virNodeDeviceObjRemove to use double pointer and set pointer to
NULL.

../../src/conf/domain_conf.c:4425:21: error: potential null pointer dereference [-Werror=null-dereference]
         switch (vcpu->hotpluggable) {
                 ~~~~^~~~~~~~~~~~~~

Validating the vcpu count is more intricate and doing it in the XML
parser will make previously valid configs (with older qemus) vanish.

Now that we have a very similar check in the qemu domain validation
callback we can do it in a more appropriate place.

This basically reverts commit b54de083.

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370066

Individual vCPU hotplug requires us to track the state of any vCPU. To
allow this add the following XML:

<domain>
  ...
  <vcpu current='2'>3</vcpu>
  <vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
    <vcpu id='1' enabled='no' hotpluggable='yes'/>
  </vcpus>
  ...

The 'enabled' attribute allows to control the state of the vcpu.
'hotpluggable' controls whether given vcpu can be hotplugged and 'order'
allows to specify the order to add the vcpus.

For some unknown reason the original implementation of the <forwarder>
element only took advantage of part of the functionality in the
dnsmasq feature it exposes - it allowed specifying the ip address of a
DNS server which *all* DNS requests would be forwarded to, like this:

   <forwarder addr='192.168.123.25'/>

This is a frontend for dnsmasq's "server" option, which also allows
you to specify a domain that must be matched in order for a request to
be forwarded to a particular server. This patch adds support for
specifying the domain. For example:

   <forwarder domain='example.com' addr='192.168.1.1'/>
   <forwarder domain='www.example.com'/>
   <forwarder domain='travesty.org' addr='10.0.0.1'/>

would forward requests for bob.example.com, ftp.example.com and
joe.corp.example.com all to the DNS server at 192.168.1.1, but would
forward requests for travesty.org and www.travesty.org to
10.0.0.1. And due to the second line, requests for www.example.com,
and odd.www.example.com would be resolved by the libvirt network's own
DNS server (i.e. thery wouldn't be immediately forwarded) even though
they also match 'example.com' - the match is given to the entry with
the longest matching domain. DNS requests not matching any of the
entries would be resolved by the libvirt network's own DNS server.

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

If you define a libvirt virtual network with one or more IP addresses,
it starts up an instance of dnsmasq. It's always been possible to
avoid dnsmasq's dhcp server (simply don't include a <dhcp> element),
but until now it wasn't possible to avoid having the DNS server
listening; even if the network has no <dns> element, it is started
using default settings.

This patch adds a new attribute to <dns>: enable='yes|no'. For
backward compatibility, it defaults to 'yes', but if you don't want a
DNS server created for the network, you can simply add:

   <dns enable='no'/>

to the network configuration, and next time the network is started
there will be no dns server created (if there is dhcp configuration,
dnsmasq will be started with "port=0" which disables the DNS server;
if there is no dhcp configuration, dnsmasq won't be started at all).

The new forward mode 'open' is just like mode='route', except that no
firewall rules are added to assure that any traffic does or doesn't
pass. It is assumed that either they aren't necessary, or they will be
setup outside the scope of libvirt.

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

Modify virDomainDefGetVcpuSched to emit an error message if
virDomainDefGetVcpu returns NULL meaning the vcpu could not
be found. Prior to commit id '9cc931f0' the error message
would have been issued in virDomainDefGetVcpu.

When commit id '6dfb4507' refactored where the iothreadsched data was
stored, the error message for when the virDomainIOThreadIDFind failed
to find an iothreadid ("iothreadsched attribute 'iothreads' uses
undefined iothread ids") was lost. This led to the possibility that
someone would try to use it, but receive the generic message "An error
occurred, but the cause is unknown".

This patch adds the error message back so that someone will know that
they have an invalid configuration.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If any of the devices referenced a USB hub that does not exist,
defining the domain would either fail with:
error: An error occurred, but the cause is unknown
(if only the last hub in the path is missing)
or crash.

Return a proper error instead of crashing.

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

The array needs to be freed too, not just its members.

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