This way we can safely differentiate what XMLs contain whole domain
definitions and which contain just devices.  Thanks to that we can
test the domain XMLs in virschematest again.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This makes the search for related XMLs easier, plus they are not used in
the xml2argv tests anyway.  This also makes future patches cleaner.
While on that remove unnecessary '-hotplug' from the filenames.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In the mock, we have a stub for virNetDevTapCreate(). However,
the mocked version does not exactly as it's native counterpart.
The function receives a string, which is an interface name that
caller would like to have, but it's not guaranteed that they will
get just that one. If they don't, the function free()-s the one
passed and returns the new one. Just like the mocked version. But
what is the mocked version missing is the free().

==1068== 6 bytes in 1 blocks are definitely lost in loss record 9 of 132
==1068==    at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==1068==    by 0xDE13356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==1068==    by 0xAE2333E: virXMLPropString (virxml.c:479)
==1068==    by 0xAE45975: virDomainNetDefParseXML (domain_conf.c:9038)
==1068==    by 0xAE5C0BB: virDomainDefParseXML (domain_conf.c:16734)
==1068==    by 0xAE5EB96: virDomainDefParseNode (domain_conf.c:17444)
==1068==    by 0xAE5EA05: virDomainDefParse (domain_conf.c:17391)
==1068==    by 0xAE5EA93: virDomainDefParseFile (domain_conf.c:17415)
==1068==    by 0x433430: testCompareXMLToArgvFiles (qemuxml2argvtest.c:278)
==1068==    by 0x433A18: testCompareXMLToArgvHelper (qemuxml2argvtest.c:414)
==1068==    by 0x446ED4: virTestRun (testutils.c:179)
==1068==    by 0x43A099: mymain (qemuxml2argvtest.c:1016)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It's just test, but why leak it?

==26971== 20 bytes in 1 blocks are definitely lost in loss record 623 of 704
==26971==    at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==26971==    by 0xE560447: vasprintf (vasprintf.c:76)
==26971==    by 0xAE0DEE2: virVasprintfInternal (virstring.c:480)
==26971==    by 0xAE0DFF7: virAsprintfInternal (virstring.c:501)
==26971==    by 0x4751F3: qemuProcessPrepareMonitorChr (qemu_process.c:2651)
==26971==    by 0x4334B1: testCompareXMLToArgvFiles (qemuxml2argvtest.c:297)
==26971==    by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==26971==    by 0x446E7A: virTestRun (testutils.c:179)
==26971==    by 0x445D33: mymain (qemuxml2argvtest.c:2029)
==26971==    by 0x44886F: virTestMain (testutils.c:969)
==26971==    by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: NMichal Privoznik <mprivozn@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>

#virsh list --uuid --name
49c765a0-25e7-40d0-964f-dac99724b32c   c7
918f1dd6-b19f-412b-ba17-d113bad89af8   f23
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.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.

Status XML tests were done by prepending a constant string to an
existing XML. With the planned changes the header will depend on data
present in the definition rather than just on the data that was parsed.

The first dynamic element in the header will be the vcpu thread list.
Reuse and rename qemuXML2XMLPreFormatCallback for gathering the relevant
data when checking the active XML parsing and formating and pass the
bitmap to a newly crated header generator.

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.

The new function works as expected, and matches the current level of
autocomplete offered, along with several other improvements like quotes
handling, multiple command completion and space handling. Now, it is easy
to introduce options completer here.
Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>

A bool 'report' has been introduced in various functions, which when set
to true will produce the error it is suppposed to produce, and when
false, will suppress the error. These functions are used in the next
patch for auto-completion.
Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>

Use unsigned int for array indexes and size_t for length variables.
Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>

Decompose vshCmddefOptParse into two helper functions, vshCmddefOptFill
and vshCmddefCheckInternals.

vshCmddefCheckInternals checks if the internal command definitions are
correct or not.

vshCmddefOptFill keeps track of the required options and mandatory
arguments through opts_required and opts_need_arg.
Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>

Before pushing this test, I changed the appropriate args file
to pet test-wrap-argv.pl, but forgot to change the xml file, so
update it accordingly.

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>

A simpe getopt-based argument parser is added for the /usr/sbin/bhyve command,
loosely based on its argument parser, which reads the following from the bhyve
command line string:

* vm name
* number of vcpus
* memory size
* the time offset (UTC or localtime)
* features:
  * acpi
  * ioapic: While this flag is deprecated in FreeBSD r257423, keep checking for
    it for backwards compatibiility.
* the domain UUID; if not explicitely given, one will be generated.
* lpc devices: for now only the com1 and com2 are supported. It is required for
   these to be /dev/nmdm[\d+][AB], and the slave devices are automatically
   inferred from these to be the corresponding end of the virtual null-modem
   cable: /dev/nmdm<N>A <-> /dev/nmdm<N>B
* PCI devices:
  * Disks: these are numbered in the order they are found, for virtio and ahci
    disks separately. The destination is set to sdX or vdX with X='a'+index;
    therefore only 'z'-'a' disks are supported.
    Disks are considered to be block devices if the path
    starts with /dev, otherwise they are considered to be files.
  * Networks: only tap devices are supported. Since it isn't possible to tell
    the type of the network, VIR_DOMAIN_NET_TYPE_ETHERNET is assumed, since it
    is the most generic. If no mac is specified, one will be generated.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>

First, remove escaped newlines and split up the string into an argv-list for
the bhyve and loader commands, respectively. This is done by iterating over the
string splitting it by newlines, and then re-iterating over each line,
splitting it by spaces.

Since this code reuses part of the code of qemu_parse_command.c
(in bhyveCommandLine2argv), add the appropriate copyright notices.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>

Unconditionally use gnulib's getopt module. This is needed by the bhyve driver
to provide a reentrant interface for getopt.

Several gnulib headers rely on features.h being included by ctype.h to provide
__GNUC_PREREQ, but on systems without glibc, this is not provided. In these
cases __GNUC_PREREQ gets redefined to 0, which causes build errors from checks
in src/internal.h.
Therefore, define __GNUC_PREREQ as early as possible. config-post.h is probably
the first header that is included, before any other headers.

As the empty bitmap exists, we should also test it. This patch adds
test cases for the procedures 'virBitmapNextSetBit', 'virBitmapLastSetBit',
'virBitmapNextClearBit'.
Tested-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

As there is an explicit constructor for the special case of empty
bitmaps, we should mention that the generic constructors rejects the
creation of empty bitmaps.
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

Before the variable 'bits' was initialized with 0 (commit
3470cd86), the following bug was
possible.

A function call with an empty bitmap leads to undefined
behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0
and 'sz == 1'. So the non global and non static variable 'bits' would
have never been set. Consequently the check 'bits == 0' results in
undefined behavior.

This patch clarifies the current version of the function by handling the
empty bitmap explicitly. Also, for an empty bitmap there is obviously no
bit set so we can just return -1 (indicating no bit set) right away. The
explicit check for 'bits == 0' after the loop is unnecessary because we
only get to this point if no set bit was found.
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>