In an unlikely event of execve() failing, the virCommandExec()
function does not report any error, even though checks that are
at the beginning of the function are verbose when failing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The modification of .volWipe callback wipes ploop volume using one of
given wiping algorithm: dod, nnsa, etc.
However, in case of ploop volume we need to reinitialize root.hds and DiskDescriptor.xml.

v2:
- added check on ploop tools presens
- virCommandAddArgFormat changed to virCommandAddArg
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

<devices>
  <iommu model='intel'/>
</devices>

results in:

-device intel-iommu

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

Check whether QEMU supports -device intel-iommu

Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.

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

A device with an attribute 'model', with just one model
so far:

<devices>
  ...
  <iommu model='intel'/>
</devices>

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

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently many users of virConf APIs are defining the same
macros for calling virConfValue() and then doing type
checking. To remove this repeated code, add a set of
typesafe accessor methods.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If the config file does not end with a \n, the parser will append
one. When re-allocating the array though, it is mistakenly assuming
that 'len' is the length including the trailing NUL, but it does
not. So we must add 2 to len, when reallocating, not 1.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This one's a bit more complicated. In qemuProcessPrepareDomain()
a master key for encrypting secret for ciphered disks is created.
This object lives within qemuDomainObjPrivate object. It is freed
in qemuProcessStop(), but if nobody calls it (for instance like
our qemuxml2argvtest does), the key object leaks.

==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707
==17078==    at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==17078==    by 0xAD924DF: virAllocN (viralloc.c:191)
==17078==    by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166)
==17078==    by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678)
==17078==    by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913)
==17078==    by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542)
==17078==    by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==17078==    by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==17078==    by 0x446E7A: virTestRun (testutils.c:179)
==17078==    by 0x445BD9: mymain (qemuxml2argvtest.c:2022)
==17078==    by 0x44886F: virTestMain (testutils.c:969)
==17078==    by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just like every other qemuBuild*CommandLine() function, this uses
a buffer to hold partial cmd line strings too. However, if
there's an error, the control jumps to 'cleanup' label leaving
the buffer behind and thus leaking it.

==2013== 1,006 bytes in 1 blocks are definitely lost in loss record 701 of 711
==2013==    at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==2013==    by 0x4C2C32F: realloc (vg_replace_malloc.c:692)
==2013==    by 0xAD925A8: virReallocN (viralloc.c:245)
==2013==    by 0xAD95EA8: virBufferGrow (virbuffer.c:130)
==2013==    by 0xAD95F78: virBufferAdd (virbuffer.c:165)
==2013==    by 0x5097F5: qemuBuildCpuModelArgStr (qemu_command.c:6339)
==2013==    by 0x509CC3: qemuBuildCpuCommandLine (qemu_command.c:6437)
==2013==    by 0x51142C: qemuBuildCommandLine (qemu_command.c:9174)
==2013==    by 0x47CA3A: qemuProcessCreatePretendCmd (qemu_process.c:5546)
==2013==    by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==2013==    by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==2013==    by 0x446E7A: virTestRun (testutils.c:179)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When storage secret is parsed in virStorageEncryptionSecretParse(),
virSecretLookupParseSecret() which allocates some memory. This is
however never freed.

==21711== 134 bytes in 6 blocks are definitely lost in loss record 70 of 85
==21711==    at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==21711==    by 0xBCA0356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==21711==    by 0xA9F432E: virXMLPropString (virxml.c:479)
==21711==    by 0xA9D25B0: virSecretLookupParseSecret (virsecret.c:70)
==21711==    by 0xA9D616E: virStorageEncryptionSecretParse (virstorageencryption.c:172)
==21711==    by 0xA9D66B2: virStorageEncryptionParseXML (virstorageencryption.c:281)
==21711==    by 0xA9D68DF: virStorageEncryptionParseNode (virstorageencryption.c:338)
==21711==    by 0xAA12575: virDomainDiskDefParseXML (domain_conf.c:7606)
==21711==    by 0xAA2CAC6: virDomainDefParseXML (domain_conf.c:16658)
==21711==    by 0xAA2FC75: virDomainDefParseNode (domain_conf.c:17472)
==21711==    by 0xAA2FAE4: virDomainDefParse (domain_conf.c:17419)
==21711==    by 0xAA2FB72: virDomainDefParseFile (domain_conf.c:17443)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

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

Setting up cgroups and other things for all kinds of threads (the
emulator thread, vCPU threads, I/O threads) was copy-pasted every time
new thing was added.  Over time each one of those functions changed a
bit differently.  So create one function that does all that setup and
start using it, starting with I/O thread setup.  That will shave some
duplicated code and maybe fix some bugs as well.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The code in qemuDomainObjPrivateXMLParseVcpu for parsing
the 'idstr' string was comparing the overall boolean
result against 0 which was always true

qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu':
qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]
     if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
                                                           ^

It was further performing two distinct error checks in
the same conditional and reporting a single error message,
which was misleading in one of the two cases.

This splits the conditional check into two parts with
distinct error messages and fixes the logic error.

Fixes the bug in

  commit 5184f398
  Author: Peter Krempa <pkrempa@redhat.com>
  Date:   Fri Jul 1 14:56:14 2016 +0200

    qemu: Store vCPU thread ids in vcpu private data objects
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

An error in virHostCPUGetKVMMaxVCPUs() means we've been unable
to access /dev/kvm, or we're running on a platform that doesn't
support KVM in the first place.

If that's the case, we shouldn't ignore the error and report
domcapabilities even though we know the user won't be able to
start any KVM guest.

All Linux releases we support (RHEL6 era) include these
definitions.

If we don't HAVE_LINUX_KVM_H, we can't query /dev/kvm to discover
the limits on the number of vCPUs, so we report an error and
return a negative value instead.

Rather than storing them in an external array store them directly.

Note the vcpu ID so that once we allow non-contiguous vCPU topologies it
will be possible to pair thread id's with the vcpus.

Further patches will be adding index and modifying the source variables
so this will make it more clear.

Members will be added in follow-up patches.

Allow to store driver specific data on a per-vcpu basis.

Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.

Most callers make sure that it's never called with an out of range vCPU.
Every other caller reports a different error explicitly. Drop the error
reporting and clean up some dead code paths.

Our copy functions format and parse XML thus are not able to copy data.
Annotate the private data pointers that this is happening.

A simple getopt-based argument parser is added for the /usr/sbin/bhyveload
command, loosely based on its argument parser.

The boot disk is guessed by iterating over all
disks and matching their sources. If any non-default arguments are found,
def->os.bootloaderArgs is set accordingly, and the bootloader is treated as a
custom bootloader.

Custom bootloader are supported by setting the def->os.bootloader and
def->os.bootloaderArgs accordingly

grub-bhyve is also treated as a custom bootloader. Since we don't get the
device map in the native format anyways, we can't reconstruct the complete
boot order. While it is possible to check what type the grub boot disk is by
checking if the --root argument is "cd" or "hd0,msdos1", and then just use the
first disk found, implementing the grub-bhyve argument parser as-is in the
grub-bhyve source would mean adding a dependency to argp or duplicating lots
of the code of argp. Therefore it's not really worth implementing that now.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>