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>

Introduce a qemu capability for -device nvdimm.
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>

Frankly, this function is one big mess. A lot of arguments,
complicated behaviour. It's really surprising that arguments were
in random order (input and output arguments were mixed together),
the documentation was outdated, the description of return values
was bogus.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Even though this variable contains just values from an enum where
zero has the usual meaning, it's enum after all and we should
check it as such.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is an input argument. We should not overwrite it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Introduce config file support for the bhyve driver. The only available
setting at present is 'firmware_dir' for specifying a directory with
UEFI firmware files.

The description should be in the target for a volume not a pool.

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>

The function is now called virQEMUCapsProbeHostCPU. Both the refactoring
and the change of the name is done for consistency with a new function
which will be introduced in the following commit.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When creating host CPU definition usable with a given emulator, the CPU
should not be defined using an unsupported CPU model. The new @models
and @nmodels parameters can be used to limit CPU models which can be
used in the result.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The parameter can be used to request either VIR_CPU_TYPE_HOST (which has
been assumed so far) or VIR_CPU_TYPE_GUEST definition.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpuNodeData has always been followed by cpuDecode as no hypervisor
driver is really interested in raw CPUID data for a host CPU. Let's
create a new CPU driver API which returns virCPUDefPtr directly.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Add an entry about virt-host-validate bhyve support and
update the driver's page.

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

Yeah, that's right. A mount point doesn't have to be a directory.
It can be a file too. However, the code that tries to preserve
mount points under /dev for new namespace for qemu does not count
with that option.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

VIR_CONNECT_LIST_STORAGE_POOLS_VSTORAGE and
VIR_CONNECT_LIST_STORAGE_POOLS_ZFS were added to libvirt but the listing
API was not properly updated to use them.

https://bugzilla.redhat.com/show_bug.cgi?id=1431543Signed-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>

Extend domain capabilities XML with the information about
available UEFI firmware files. It searches in the location
that the sysutils/bhyve-firmware FreeBSD port installs
files to.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

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

Allow to boot using UEFI rather than using an external boot loader
such as bhyveload or grub-bhyve.

Also, make LPC PCI-ISA bridge handling more flexible as now it's
needed not only for serial ports, but for bootrom as well.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Implement the BHACE_CAP_LPC_BOOTROM capability by checking the stderr
output of 'bhyve -l bootrom'. If the bootrom option is unsupported, this
will contain the following output:

    bhyve: invalid lpc device configuration 'bootrom'

On newer bhyve versions that do support specifying a bootrom image, the
standard help will be printed.

Add bhyve support to virt-host-validate(1). It checks for the
essential kernel modules to be available so that user can actually
start VMs, have networking and console access.

It uses the kldnext(2)/kldstat(2) routines to retrieve modules list.
As bhyve is only available on FreeBSD and these routines were available
long before bhyve appeared, not adding any specific configure checks
for that.

Also, update tools/Makefile.am to add
virt-host-validate-$driver.[hc] to the build only if the
appropriate driver is enabled.

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>

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

If a qemu process has died, we get EOF on its monitor. At this
point, since qemu process was the only one running in the
namespace kernel has already cleaned the namespace up. Any
attempt of ours to enter it has to fail.

This really happened in the bug linked above. We've tried to
attach a disk to qemu and while we were in the monitor talking to
qemu it just died. Therefore our code tried to do some roll back
(e.g. deny the device in cgroups again, restore labels, etc.).
However, during the roll back (esp. when restoring labels) we
still thought that domain has a namespace. So we used secdriver's
transactions. This failed as there is no namespace to enter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This documents the preferred conventions for naming files,
structs, enums, typedefs and functions.
Signed-off-by: NDaniel P. Berrange <berrange@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>

If the delivery of the DEVICE_DELETED event for the vCPU being deleted
would time out, the code would not call 'qemuDomainResetDeviceRemoval'.

Since the waiting thread did not unregister itself prior to stopping the
waiting the monitor code would try to wake it up instead of dispatching
it to the event worker. As a result the unplug process would not be
completed and the definition would not be updated.

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

Note that the waiting thread is signaled in the debug logs to simplify
debugging.

This reverts commit c96bd78e.

So our code is one big mess and we modify domain definition while
building qemu_command line and our hotplug code share only part
of the parsing and command line building code.  Let's revert
that change because to fix it properly would require refactor and
move a lot of things.

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

Even though scsi storage driver builds fine on non-Linux, it
will not work properly because it relies on Linux procfs, so
disable that in configure if we're not building for Linux.

We should skip <listen type='socket'/> only if the 'socket' path
is specified because if there is no 'socket' path we need to
keep that element in migratable XML.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1366088Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When libvirtd is started we call qemuDomainRecheckInternalPaths
to detect whether a domain has VNC socket path generated by libvirt
based on option from qemu.conf.  However if we are parsing status XML
for running domain the existing socket path can be generated also if
the config XML uses the new <listen type='socket'/> element without
specifying any socket.

The current code doesn't make difference how the socket was generated
and always marks it as "fromConfig".  We need to store the
"autoGenerated" value in the status XML in order to preserve that
information.

The difference between "fromConfig" and "autoGenerated" is important
for migration, because if the socket is based on "fromConfig" we don't
print it into the migratable XML and we assume that user has properly
configured qemu.conf on both hosts.  However if the socket is based
on "autoGenerated" it means that a new feature was used and therefore
we need to leave the socket in migratable XML to make sure that if
this feature is not supported on destination the migration will fail.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Rename 'secretUsageType' to 'usageType' since it's superfluous in an
API qemu*Secret*