Make sure we only assign the default spicevmc channel name to spicevmc
virtio channels. Caused by commits 3269ee65 and 1133ee2b, which moved
the assignment from XML parsing code to QEMU but failed to keep the
logic.

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

So far the argument has not much meaning and was practically ignored.
This is not good since when doing memory hotplug, the size of desired
hugepage backing is passed in that argument. Taking closer look at the
tests I'm fixing reveals the bug. For instance, while the following is
in the test:

    <memory model='dimm'>
      <source>
        <nodemask>1-3</nodemask>
        <pagesize unit='KiB'>4096</pagesize>
      </source>
      <target>
        <size unit='KiB'>524287</size>
        <node>0</node>
      </target>
      <address type='dimm' slot='0' base='0x100000000'/>
    </memory>

the generated commandline corresponding to this XML was:

    -object memory-backend-ram,id=memdimm0,size=536870912,\
    host-nodes=1-3,policy=bind

Have you noticed? Yes, memory-backend-ram! Nothing can be further away
from the right answer. The hugepage backing is requested in the XML
and we happily ignore it. This is just not right. It's
memory-backend-file which should have been used:

    -object memory-backend-file,id=memdimm0,prealloc=yes,\
    mem-path=/dev/hugepages4M/libvirt/qemu,size=536870912,\
    host-nodes=1-3,policy=bind

The problem is, that @pagesize passed to qemuBuildMemoryBackendStr
(where this part of commandline is built) was ignored. The hugepage to
back memory was searched only and only by NUMA nodes pinning. This
works only for regular guest NUMA nodes.

Then, I'm changing the hugepages size in the test XMLs too. This is
simply because in the test suite we create dummy mount points just for
2M and 1G hugepages. And in the test 4M was requested. I'm sticking to
2M, but 1G should just work too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

This function constructs the backend (host facing) part of the
memory device.  At the beginning, the configured hugepages are
searched to find the best match for given guest NUMA node.
Configured hugepages can have a @nodeset attribute to specify on
which guest NUMA nodes should be the hugepages backing used.
There is, however, one 'corner case'. Users may just tell 'use
hugepages to back all the nodes'. In other words:

  <memoryBacking>
    <hugepages/>
  </memoryBacking>

  <cpu>
    <numa>
      <cell id='0' cpus='0-1' memory='1024000' unit='KiB'/>
    </numa>
  </cpu>

Our code fails in this case. Well, since there's no @nodeset (nor
any <page/> child element to <hugepages/>) we fail to lookup the
default hugepage size to use.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Adding a test for the new watchdog model diag288.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Adding a test for the new watchdog action "inject-nmi".
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

The privileged flag will not change while the configuration might
change. Make the 'privileged' flag member of the driver again and mark
it immutable. Should that ever change add an accessor that will group
reads of the state.

I needed to specify the iobase address for certain exotic mips configurations.
Signed-off-by: NJames Cowgill <james410@cowgill.org.uk>

This patch adds the support of queues attribute of the driver element
for vhost-user interface type. Example:

<interface type='vhostuser'>
      <mac address='52:54:00:ee:96:6d'/>
      <source type='unix' path='/tmp/vhost2.sock' mode='client'/>
      <model type='virtio'/>
      <driver queues='4'/>
</interface>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1207692Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using
qemu-system-aarch64 KVM to run armv7l VMs.

Add a capabilities check for it, wire it up in qemu_command, and test
the command line generation.

The guest firmware provides the same functionality as the pvpanic
device, and the relevant element should always be present in the
domain XML to reflect this fact, so add it after parsing the
definition if it wasn't there already.

The guest firmware provides the same functionality as the pvpanic
device, which is not available in QEMU on pSeries, so the domain
XML should be allowed to contain the <panic> element.

On the other hand, unlike the pvpanic device, the guest firmware
can't be configured, so report an error if an address has been
provided in the XML.

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

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

Implementation is pretty straight-forward. Of course, not all qemus
out there supports the device, so new capability is introduced and
checked prior each use of the device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Test the support for enabling/disabling CPACF protected key management
operations for a guest.
Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Back in 2013, commit 877bc089 added in some tests that made sure no
error was generated on a domain definition that had an automatically
added usb controller if that domain didn't have a PCI bus to attach
the usb controller to. This was done because, at that time, libvirt
was automatically adding a usb controller to *any* domain definition
that didn't have one.  Along with permitting the controller, two
s390-specific tests were added to ensure this behavior was maintained
- one with <controller type='usb' model='none'/> and another (called
"s390-piix-controllers") that had both usb and ide controllers, but
nothing attached to them.

Then in February of this year, commit 09ab9dcc eliminated the annoying
auto-adding of a usb device for s390 and s390x machines, stating:

 "Since s390 does not support usb the default creation of a usb
  controller for a domain should not occur."

Although, as verified here, the s390 doesn't support usb, and usb
controllers aren't currently added to s390 domain definitions
automatically, there are likely still some domain definitions in the
wild that have a usb controller (which was added *by libvirt*, not by
the user), so we will keep the tests verifying that behavior for
now. But this patch changes the names of the tests to reflect that
they don't actually contain a valid s390 config; this way future
developers won't propagate the incorrect idea that an s390 virtual
machine can have a USB (or IDE) bus.

In the case of the IDE controller, though, libvirt has never
automatically added an IDE controller unless a user added an IDE disk
(which itself would have caused an error), and we specifically *do*
want to begin generating an error when someone tries to add an IDE
controller to a domain that can't support one. For that reason, while
renaming the sz390-piix-controllers patch, this patch removes the
<controller type='ide'...> from it (otherwise the upcoming patch would
break make check)

My commit 747761a7 (v1.2.15 only) dropped this bit of logic when filling
in a default arch in the XML:

-    /* First try to find one matching host arch */
-    for (i = 0; i < caps->nguests; i++) {
-        if (caps->guests[i]->ostype == ostype) {
-            for (j = 0; j < caps->guests[i]->arch.ndomains; j++) {
-                if (caps->guests[i]->arch.domains[j]->type == domain &&
-                    caps->guests[i]->arch.id == caps->host.arch)
-                    return caps->guests[i]->arch.id;
-            }
-        }
-    }

That attempt to match host.arch is important, otherwise we end up
defaulting to i686 on x86_64 host for KVM, which is not intended.
Duplicate it in the centralized CapsLookup function.

Additionally add some testcases that would have caught this.

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

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>

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>

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).

- 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.

Replaces a common pattern used in many test files

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

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.

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

Request that the number be parsed as decimal, to allow 08
and 09.

Format it with the leading zero, 1.01 and 1.10 are two
different versions.

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

In virDomainVirtioSerialAddrNext, add another controller
if we've exhausted all ports of the existing controllers.

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

Add a test to demonstrate the effect of automatic virtio-serial
address assignment.

On IRC, Hydrar pointed a problem where 'virsh edit' failed on
his domain created through an ISCSI pool managed by virt-manager,
all because the XML included a block device with colons in the
name.

* docs/schemas/basictypes.rng (absFilePath): Add colon as safe.
* tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.xml: New file.
* tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.args: Likewise.
* tests/qemuxml2argvtest.c (mymain): Test it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Starting a qemu VM with a memory module that has the base address
specified results in the following error:

 error: internal error: early end of file from monitor: possible problem:
 2015-03-26T03:45:52.338891Z qemu-kvm: -device pc-dimm,node=0,memdev=memdimm0,
 id=dimm0,slot=0,base=4294967296: Property '.base' not found

The correct property name for the base address is 'addr'.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

QEMU 2.3 adds these new models to cover Haswell and Broadwell CPUs with
updated microcode. Luckily, they also reverted former the machine type
specific changes to existing models. And since these changes were never
released, we don't need to hack around them in libvirt.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Add support to start qemu instance with 'pc-dimm' device. Thanks to the
refactors we are able to reuse the existing function to determine the
parameters.

To enable memory hotplug the maximum memory size and slot count need to
be specified. As qemu supports now other units than mebibytes when
specifying memory, use the new interface in this case.

Now that the size of guest's memory can be inferred from the NUMA
configuration (if present) make it optional to specify <memory>
explicitly.

To make sure that memory is specified add a check that some form of
memory size was specified. One side effect of this change is that it is
no longer possible to specify 0KiB as memory size for the VM, but I
don't think it would be any useful to do so. (I can imagine embedded
systems without memory, just registers, but that's far from what libvirt
is usually doing).

Forbidding 0 memory for guests also fixes a few corner cases where 0 was
not interpreted correctly and caused failures. (Arguments for numad when
using automatic placement, size of the balloon). This fixes problems
described in https://bugzilla.redhat.com/show_bug.cgi?id=1161461

Test case changes are added to verify that the schema change and code
behave correctly.

Commit 3e4b783e fixed an issue with RNG schema where this address type
was missing, this commit adds a test for it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We have something like pvpanic device. However, in some cases it does
not have any address assigned, in which case we produce this ugly XML
(still valid though):

  <devices>
    <emulator>/usr/bin/qemu</emulator>
    ...
    <panic>
    </panic>
  </devices>

Lets format "<panic/>" instead.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

There's been a bug report appearing on the qemu-devel list, that
libvirt is unable to pass spaces in disk serial number [1]. Not only
our RNG schema forbids that, the code is not prepared either. However,
with a bit of escaping (if needed) we can allow spaces there.

1: https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg04041.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>