My commit 7b9de914 added some aarch64 CPU test cases. I wanted to test
two different code paths but inadvertently added two of the same test
cases.

The second code path (using <cpu><model>host</model</cpu>) isn't easily
exercised via the qemu tests anyways, I'll need to look elsewhere.

Regardless, remove the redundant tests for now

The only version that's supported in QEMU is version 2, currently.
Fortunately, it is enabled by aarch64 automatically, so there's
nothing for us that needs to be put onto command line.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Replace all occurrences of "stream write to differences to"
with "stream to write differences to".

Check that the vmport feature is correctly used in qemu commande line.

Only USB addresses are allowed for USB disks. Report an error if another
address is configured.

https://bugzilla.redhat.com/show_bug.cgi?id=1043436Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=858147Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The phyp driver stuffed it into a DomainDefPtr during its attachdevice
routine, but the value is never advertised via capabilities so it should
be safe to drop.

Have the phyp driver use OSTYPE_LINUX, which is what it advertises via
capabilities.

Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The free callback should be qemuMonitorChardevInfoFree rather
than just 'free' when virHashCreate'ing the chardevInfo hash.

==29959== 24 bytes in 2 blocks are definitely lost in loss record 19 of 53
==29959==    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29959==    by 0xB95C679: strdup (in /lib64/libc-2.20.so)
==29959==    by 0x63C6546: virStrdup (virstring.c:709)
==29959==    by 0x4805ED: qemuMonitorJSONExtractChardevInfo (qemu_monitor_json.c:3429)
==29959==    by 0x4807A5: qemuMonitorJSONGetChardevInfo (qemu_monitor_json.c:3479)
==29959==    by 0x434AEC: testQemuMonitorJSONqemuMonitorJSONGetChardevInfo (qemumonitorjsontest.c:1824)
==29959==    by 0x436F2F: virtTestRun (testutils.c:211)
==29959==    by 0x436932: mymain (qemumonitorjsontest.c:2404)
==29959==    by 0x4382EA: virtTestMain (testutils.c:863)
==29959==    by 0x436B27: main (qemumonitorjsontest.c:2423)
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>

Replace with just VIR_FREE.

Rather than have a separate routine to parse the alias of an iothread
returned from qemu in order to get the iothread_id value, parse the alias
when returning and just return the iothread_id in qemuMonitorIOThreadInfoPtr

This set of patches removes the function, changes the "char *name" to
"unsigned int" and handles all the fallout.

Commit ca329299 added a utility function virtTestCompareFiles() to
eliminate repetitive code in several test programs. It unfortunately
calls virtTestDifference() with the arguments in the wrong order -
strcontent is the "actual" output gathered by the test rig, while
filecontent is the "expected", and virtTestDifference() wants expected
(filecontent) followed by actual (strcontent), but
virtTestCompareFiles() does the opposite, which can make the output a
bit confusing when there is a failure.

With iothreadid's allowing any 'id' value for an iothread_id, the
iothreadsched code needs a slight adjustment to allow for "any"
unsigned int value in order to create the bitmap of ids that will
have scheduler adjustments. Adjusted the doc description as well.

Remove the iothreadspin array from cputune and replace with a cpumask
to be stored in the iothreadids list.

Adjust the test output because our printing goes in order of the iothreadids
list now.

Add 'thread_id' to the virDomainIOThreadIDDef as a means to store the
'thread_id' as returned from the live qemu monitor data.

Remove the iothreadpids list from _qemuDomainObjPrivate and replace with
the new iothreadids 'thread_id' element.

Rather than use the default numbering scheme of 1..number of iothreads
defined for the domain, use the iothreadid's list for the iothread_id

Since iothreadids list keeps track of the iothread_id's, these are
now used in place of the many places where a for loop would "know"
that the ID was "+ 1" from the array element.

The new tests ensure usage of the <iothreadid> values for an exact number
of iothreads and the usage of a smaller number of <iothreadid> values than
iothreads that exist (and usage of the default numbering scheme).

All the libraries use same parameters when building, why not have it in
one place at the begining of the Makefile.

This will also ensure no new mock library will have a problem with
missing e.g. MINGW_EXTRA_LDFLAGS.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In a lot places we use path like this:

  $(srcdir)/../src/....

when in fact it can be:

  $(top_srcdir)/src/
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This fix should completely close
https://bugzilla.redhat.com/show_bug.cgi?id=1214605Signed-off-by: NPavel Fedin <p.fedin@samsung.com>

Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>

Commit ca329299 caused build errors in bhyvexml2argvtest.c because of
some undefined variables.

Pushing under the build breaker rule.

- Make sure aarch64 host-passthrough works correctly
- Make sure libvirt doesn't choke on cpu model=host, which is what
  virt-install/virt-manager were incorrectly specifying up until recently.

If this enviroment variable is set, the virTestCompareToFile helper
will overwrite the file content we are comparing against, if the
file doesn't exist or it doesn't match the expected input.

This is useful when adding new test cases, or making changes that
generate a lot of output churn.

Replaces a common pattern used in many test files

To remove a bunch of TestGetDebug()/TestGetVerbose() checks

The PortNumber data type is declared to derive from 'short'.
Unfortunately this is an signed type, so validates the range
[-32,768, 32,767] which excludes valid port numbers between
32767 and 65535.

We can't use 'unsignedShort', since we need -1 to be a valid
port number too.

This change is to use 'int' and set an explicit max boundary
instead of relying on the data types' built-in max.

One of the existing tests is changed to use a high port number
to validate the schema.

https://bugzilla.redhat.com/show_bug.cgi?id=1214664Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 835cf84b dropped expectedVirtTypes argument for
virDomainDefParse*() functions, however bhyve tests still try to pass
that to virDomainDefParseFile(), therefore build fails.

Fix build by fixing virDomainDefParseFile() usage.

When building without lxc support enabled, build fails with:

CLD     vircapstest
vircapstest.o: In function `test_virCapsDomainDataLookupLXC':
vircapstest.c:(.text+0x9ef): undefined reference to `testLXCCapsInit'

Fix that by hiding LXC tests under appropriate #ifdef. Same applies
for QEMU and XEN.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This needs to specified in way too many places for a simple validation
check. The ostype/arch/virttype validation checks later in
DomainDefParseXML should catch most of the cases that this was covering.

This revealed that GuestDefaultEmulator was a bit buggy, capable
of returning an emulator that didn't match the passed domain type. Fix
up the test suite input to continue to pass.

This is a helper function to look up all capabilities data for all
the OS bits that are relevant to <domain>. This is

- os type
- arch
- domain type
- emulator
- machine type

This will be used to replace several functions in later commits.

Rather than an opencoded string. This should be a no-op

According to docs, using 'lun' as a value for device attribute is only valid
with disk types 'block' and 'network'. However current RNG schema also allows
a combination type='file' device='lun' which results in a successfull
xml validation, but fails at qemuBuildCommandLine.
Besides fixing the RNG schema, this patch also adds a qemuxml2argvtest
for this case.

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

Currently, when constructing traffic shaping rules, the ingress
filter is created without any priority specified on the command
line. This makes kernel to make up one. While this works, it
simplifies things a bit if we provide the filter priority. In
this case, since it's the root filter lets give it the highest
priority of number 1.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add support for HVM direct kernel boot in libxl.  Also add a
test to verify domXML <-> native conversions.
Signed-off-by: NChunyan Liu <cyliu@suse.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

In xl config, hvmloader is implied for hvm guests.  It is not
specified with the "kernel" option like xm config.  The "kernel"
option, along with "ramdisk" and "extra", is used for HVM direct
kernel boot.  Instead of using "kernel" option to populate
virDomainDef object's os.loader->path, use hvmloader discovered
when gathering capabilities.

This change required fixing initialization of capabilities in
the test utils and removing 'kernel = "/usr/lib/xen/boot/hvmloader"'
from the test config files.

xl and xm differ a bit in how <os> configuration is represented.
E.g. xl config supports <os><nvram .../></os> via its "bios"
setting.

Move the xenParseOS and xenFormatOS functions from xen_common.c
and copy to xen_xl.c and xen_xm.c so they can be customized for
xm vs xl config.  An unfortunate fallout is reordering of entries
in the test config files.

The <inbound/> element to <bandwidth/> has several attributes from
which two are mandatory. Well, from two at least one has to be
present: @average or @floor or both. Instead of inventing crazy RNG
schema, let's make all the attributes optional there and rely on our
parsing code to correctly handle the situation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>