Rather than returning an int and a *bitmap pointer, just return and
check a NULL bitmap pointer

It was pointed out here:

  https://bugzilla.redhat.com/show_bug.cgi?id=1331796#c4

that we shouldn't be adding a "no-resolv" to the dnsmasq.conf file for
a network if there isn't any <forwarder> element that specifies an IP
address but no qualifying domain. If there is such an element, it will
handle all DNS requests that weren't otherwise handled by one of the
forwarder entries with a matching domain attribute. If not, then DNS
requests that don't match the domain of any <forwarder> would not be
resolved if we added no-resolv.

So, only add "no-resolv" when there is at least one <forwarder>
element that specifies an IP address but no qualifying domain.

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

qemuMonitorGetGuestCPU can now optionally create CPU data from
filtered-features in addition to feature-words.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This unbreaks emulators that don't support this command such as
qemu-system-mips*.

Reference: http://bugs.debian.org/854125

We want pcie-root-ports to be used when available in QEMU,
but at the same time we need to ensure that hosts running
older QEMU releases keep working and that the user can
override the default at any time.

Add a comment for the original pcie-root-port test cases
to make it clear how these new test cases are different.

QEMU 2.9 introduces the pcie-root-port device, which is
a generic version of the existing ioh3420 device.

Make the new device available to libvirt users.

There were couple of reports on the list (e.g. [1]) that guests
with huge amounts of RAM are unable to start because libvirt
kills qemu in the initialization phase. The problem is that if
guest is configured to use hugepages kernel has to zero them all
out before handing over to qemu process. For instance, 402GiB
worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we
do not want to make the timeout for connecting to monitor
configurable, we have to teach libvirt to count with this
fact. This commit implements "1s per each 1GiB of RAM" approach
as suggested here [2].

1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html
2: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

For NVDIMM devices it is optionally possible to specify the size
of internal storage for namespaces. Namespaces are a feature that
allows users to partition the NVDIMM for different uses.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that NVDIMM has found its way into libvirt, users might want
to fine tune some settings for each module separately. One such
setting is 'share=on|off' for the memory-backend-file object.
This setting - just like its name suggest already - enables
sharing the nvdimm module with other applications. Under the hood
it controls whether qemu mmaps() the file as MAP_PRIVATE or
MAP_SHARED.

Yet again, we have such config knob in domain XML, but it's just
an attribute to numa <cell/>. This does not give fine enough
tuning on per-memdevice basis so we need to have the attribute
for each device too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So, majority of the code is just ready as-is. Well, with one
slight change: differentiate between dimm and nvdimm in places
like device alias generation, generating the command line and so
on.

Speaking of the command line, we also need to append 'nvdimm=on'
to the '-machine' argument so that the nvdimm feature is
advertised in the ACPI tables properly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

NVDIMM is new type of memory introduced into QEMU 2.6. The idea
is that we have a Non-Volatile memory module that keeps the data
persistent across domain reboots.

At the domain XML level, we already have some representation of
'dimm' modules. Long story short, NVDIMM will utilize the
existing <memory/> element that lives under <devices/> by adding
a new attribute 'nvdimm' to the existing @model and introduce a
new <path/> element for <source/> while reusing other fields. The
resulting XML would appear as:

    <memory model='nvdimm'>
      <source>
        <path>/tmp/nvdimm</path>
      </source>
      <target>
        <size unit='KiB'>523264</size>
        <node>0</node>
      </target>
      <address type='dimm' slot='0'/>
    </memory>

So far, this is just a XML parser/formatter extension. QEMU
driver implementation is in the next commit.

For more info on NVDIMM visit the following web page:

    http://pmem.io/Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

One of the main reasons for introducing host-model CPU definition in a
domain capabilities XML was the inability to express disabled features
in a host capabilities XML. That is, when a host CPU is, e.g., Haswell
without x2apic support, host capabilities XML will have to report it as
Westmere + a bunch of additional features., but we really want to use
Haswell - x2apic when creating a host-model CPU.

Unfortunately, I somehow forgot to do the last step and the code would
just copy the CPU definition found in the host capabilities XML. This
changed recently for new QEMU versions which allow us to query host CPU,
but any slightly older QEMU will not benefit from any change I did. This
patch makes sure the right CPU model is filled in the domain
capabilities even with old QEMU.

The issue was reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1426456Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This element is only allowed for host CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

bhyve supports 'gop' video device that allows clients to connect
to VMs using VNC clients. This commit adds support for that to
the bhyve driver:

 - Introducr 'gop' video device type
 - Add capabilities probing for the 'fbuf' device that's
   responsible for graphics
 - Update command builder routines to let users configure
   domain's VNC via gop graphics.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Add a new test to fchosttest in order to test creation of our vHBA
via the Storage Pool logic.  Unlike the real code, we cannot yet use
the virVHBA* API's because they (currently) traverse the file system
in order to get the parent vport capable scsi_host. Besides there's
no "real" NPIV device here - so we have to take some liberties, at
least for now.

Instead, we'll follow the node device tests partially in order to
create and destroy the vHBA with the test node devices.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This is a very historic artefact. Back in the old days of
830ba76c when we had macros to add arguments onto qemu command
line (!) we thought it was a good idea to let qemu write out the
PID file. So we passed -pidfile $stateDir/$domName onto the
command line. Thus, in order for tests to work we needed stable
stateDir in the qemu driver. Unfortunately, after 16efa11a
where stateDir is mkdtemp()-d, this approach lead to a leak of
temp dir.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Demonstrates the bug fix in commit 0e5db762

Some of our tests (e.g. qemuhotplugtest) call
virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
creates a fake qemu driver and fills it with some fake
configuration. At least so we hoped. The truth is, it calls
regular virQEMUDriverConfigNew() and then fix couple of paths.
Literally. Therefore our tests see regular stateDir and configDir
for the user that is running the tests. Directories, where live
domain XMLs are stored. Let's just hope our test suite hasn't
mangled any of them.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch adds support and documentation
for the emulation_faults perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation
for the alignment_faults perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation
for the page_faults_maj perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation
for the page_faults_min perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation
for the cpu_migrations perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation
for the context_switches perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation
for the page_faults perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation for
the task_clock perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This patch adds support and documentation for
the cpu_clock perf event.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Since the kernel does not report much data for that box the sysinfo
output is comparatively sparse.

There's no reason why we should avoid running all sysinfo tests on all
platforms. Refactor the test to get rid of the conditionally compiled
cruft.

virSysinfoSetup should be used only in tests so it can be moved to the
new header file rather than using an extern declaration.

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

Test virSystemd APIs twice to check the cache effects.