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>

Always format id first so that we don't need to do that twice in
different code paths.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit 85635600 switched from
hardcoded use of strcontent to hardcoded use of fixedcontent
(fixedcontent is *sometimes* a copy of strcontent with a \n
appended). This was a problem because sometimes fixedcontent is *not*
a copy of strcontent, but is instead NULL, leading to the regenerated
test case output being a 0 length file.

This patch creates a new const char *cmpcontent initialized to
strcontent, but changed to fixedcontent if/when fixedcontent is
created, then always uses cmpcontent instead of (str|fixed)content.

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

Most of QEMU's PCI display device models, such as:

  libvirt video/model/@type  QEMU -device
  -------------------------  ------------
  cirrus                     cirrus-vga
  vga                        VGA
  qxl                        qxl-vga
  virtio                     virtio-vga

come with a linear framebuffer (sometimes called "VGA compatibility
framebuffer"). This linear framebuffer lives in one of the PCI device's
MMIO BARs, and allows guest code (primarily: firmware drivers, and
non-accelerated OS drivers) to display graphics with direct memory access.

Due to architectural reasons on aarch64/KVM hosts, this kind of
framebuffer doesn't / can't work in

  qemu-system-(arm|aarch64) -M virt

machines. Cache coherency issues guarantee a corrupted / unusable display.
The problem has been researched by several people, including kvm-arm
maintainers, and it's been decided that the best way (practically the only
way) to have boot time graphics for such guests is to consolidate on
QEMU's "virtio-gpu-pci" device.

>From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt
supports

  <devices>
    <video>
      <model type='virtio'/>
    </video>
  </devices>

but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga"
device model. (See the qemuBuildDeviceVideoStr() function and the
"qemuDeviceVideo" enum impl.)

According to the above, this is not right for the "virt" machine type; the
qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga"
device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure
virtio device without a compatibility framebuffer, is available, and works
fine.

(The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware
for "virt" -- supports "virtio-gpu-pci", as of upstream commit
3ef3209d3028. See
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.)

Override the default mapping of "virtio", from "virtio-vga" to
"virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true.

Cc: Andrea Bolognani <abologna@redhat.com>
Cc: Drew Jones <drjones@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Martin Kletzander <mkletzan@redhat.com>
Suggested-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NMartin Kletzander <mkletzan@redhat.com>

Commit ca329299 added function
virTestCompareToFile(), but forgot to use a fixedcontent value for the
actual comparison.  That lead to VIR_TEST_DEBUG=1 showing (for some
tests) all the actual output from the first error to the end of the
string due to the difference being an endline in the end.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Just like we are running 'virsh self-test' from within our test
suite, we should run 'virt-admin self-test' too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Return whether a vcpu entry is hotpluggable or online so that upper
layers don't have to infer the information from other data.

Advantage is that this code can be tested by unit tests.

The test qemuxml2argv-serial-tcp-tlsx509-chardev.args
will fail if libvirt is built with a --sysconfdir
arg that is not /etc.  Fix this by setting a hardcoded
path in the test code.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virsh-self-test script compared the test's return code with 1 and only if
the return code matched this value then the test was marked as failed. Problem
is that SIGSEGV returns 139 (or 11 to be precise, since shell reserves the MSB
for abnormal exit signaling) which passes the check just fine and test then
appears as successful which it most certainly wasn't.
Therefore, flip the logic to compare against 0 instead and every other result
will be treated as a failed test case.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@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>

When building a chardev device string for tcp, add the necessary pieces to
access provide the TLS X.509 path to qemu.  This includes generating the
'tls-creds-x509' object and then adding the 'tls-creds' parameter to the
VIR_DOMAIN_CHR_TYPE_TCP command line.

Finally add the tests for the qemu command line. This test will make use
of the "new(ish)" /etc/pki/qemu setting for a TLS certificate environment
by *not* "resetting" the chardevTLSx509certdir prior to running the test.
Also use the default "verify" option (which is "no").
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new TLS X.509 certificate type - "chardev". This will handle the
creation of a TLS certificate capability (and possibly repository) for
properly configured character device TCP backends.

Unlike the vnc and spice there is no "listen" or "passwd" associated. The
credentials eventually will be handled via a libvirt secret provided to
a specific backend.

Make use of the default verify option as well.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

We already have the ability to turn off dumping of guest
RAM via the domain XML. This is not particularly useful
though, as it is under control of the management application.
What is needed is a way for the sysadmin to turn off guest
RAM defaults globally, regardless of whether the mgmt app
provides its own way to set this in the domain XML.

So this adds a 'dump_guest_core' option in /etc/libvirt/qemu.conf
which defaults to false. ie guest RAM will never be included in
the QEMU core dumps by default. This default is different from
historical practice, but is considered to be more suitable as
a default because

 a) guest RAM can be huge and so inflicts a DOS on the host
    I/O subsystem when dumping core for QEMU crashes

 b) guest RAM can contain alot of sensitive data belonging
    to the VM owner. This should not generally be copied
    around inside QEMU core dumps submitted to vendors for
    debugging

 c) guest RAM contents are rarely useful in diagnosing
    QEMU crashes
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

RBD in qemu still uses only the legacy 'filename' syntax.

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

Commit 2ed772cd forgot to set proper protocol. This was also present in
the test data.

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

With current perf framework, this patch adds support and documentation
for more perf events, including cache misses, cache references, cpu cycles,
and instructions.
Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>

xen-xm doesn't support mult serial devices at all, so these tests are
meaningless.
Signed-off-by: NBob Liu <bob.liu@oracle.com>

Adding tests for domXML <-> xl.cfg conversions containing multiple
serial devices.
Signed-off-by: NBob Liu <bob.liu@oracle.com>

Add support for using the new approach to hotplug vcpus using device_add
during startup of qemu to allow sparse vcpu topologies.

There are a few limitations imposed by qemu on the supported
configuration:
- vcpu0 needs to be always present and not hotpluggable
- non-hotpluggable cpus need to be ordered at the beginning
- order of the vcpus needs to be unique for every single hotpluggable
  entity

Qemu also doesn't really allow to query the information necessary to
start a VM with the vcpus directly on the commandline. Fortunately they
can be hotplugged during startup.

The new hotplug code uses the following approach:
- non-hotpluggable vcpus are counted and put to the -smp option
- qemu is started
- qemu is queried for the necessary information
- the configuration is checked
- the hotpluggable vcpus are hotplugged
- vcpus are started

This patch adds a lot of checking code and enables the support to
specify the individual vcpu element with qemu.

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.

The reported data is unusual so add it to the test suite.

Test the algorithm that extracts the order in which the vcpu entries
were plugged in on a sample of data created by plugging in vcpus
arbitrarily.

Power 8 platform's basic hotpluggable unit is a core rather than a
thread for x86_64 family. This introduces most of the complexity of the
matching code and thus needs to be tested.

The test data contain data captured from in-order cpu hotplug and
unplug operations.

During review it was reported that adding at least 11 vcpus creates a
collision of prefixes in the monitor matching algorithm. Add a test case
to verify that the problem won't happen.

As the combination algorithm is rather complex and ugly it's necessary
to make sure it works properly. Add test suite infrastructure for
testing it along with a basic test based on x86_64 platform.

To allow matching up the data returned by query-cpus to entries in the
query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract
the QOM path as it's the only link between the two.

QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
machine type. Extract and cache the information using the capability
cache.

When copying the capabilities for a new start of qemu, mask out the
presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
doesn't support hotpluggable cpus.

Prepare to extract more data by returning an array of structs rather than
just an array of thread ids. Additionally report fatal errors separately
from qemu not being able to produce data.

Turn various vshPrint() informative messages into vshPrintExtra(), so
they are not printed when requesting the quiet mode; neither XML/info
outputs nor the results of commands are affected.
Also change the expected outputs of the virsh-undefine test, since virsh
is invoked in quiet mode there.

Some informative messages might still be converted (and thus silenced
when in quiet mode), but this is an improvements nonetheless.

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

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

==18324== 32 bytes in 1 blocks are still reachable in loss record 41 of 114
==18324==    at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==18324==    by 0x4EA479B: virAlloc (viralloc.c:144)
==18324==    by 0x4EA674A: virBitmapNewQuiet (virbitmap.c:77)
==18324==    by 0x4EA67F7: virBitmapNew (virbitmap.c:106)
==18324==    by 0x4EC777D: dnsmasqCapsNewEmpty (virdnsmasq.c:801)
==18324==    by 0x4EC781B: dnsmasqCapsNewFromBuffer (virdnsmasq.c:815)
==18324==    by 0x407CF4: mymain (networkxml2conftest.c:99)
==18324==    by 0x409CF0: virTestMain (testutils.c:982)
==18324==    by 0x4080EA: main (networkxml2conftest.c:136)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The marginally nicer error message is not worth the extra lines in
cfg.mk.

Also drop the excludes since there was only one offender in the tests.