Many drivers had a comment that they did not validate the incoming
'flags' to virDomainGetXMLDesc() because they were relying on
virDomainDefFormat() to do it instead. This used to be the case
(at least since 461e0f1a and friends in 0.9.4 added unknown flag
checking in general), but regressed in commit 0ecd6851 (1.2.12),
when all of the drivers were changed to pass 'flags' through the
new helper virDomainDefFormatConvertXMLFlags(). Since this helper
silently ignores unknown flags, we need to implement flag checking
in each driver instead.

Annoyingly, this means that any new flag values added will silently
be ignored when targeting an older libvirt, rather than our usual
practice of loudly diagnosing an unsupported flag.  Add comments
in domain_conf.[ch] to remind us to be extra vigilant about the
impact when adding flags (a new flag to add data is safe if the
older server omitting the requested data doesn't break things in
the newer client; a new flag to suppress data rather than enhancing
the existing VIR_DOMAIN_XML_SECURE may form a data leak or even a
security hole).

In the qemu driver, there are multiple callers all funnelling to
qemuDomainDefFormatBufInternal(); many of them already validated
flags (and often only a subset of the full set of possible flags),
but for ease of maintenance, we can also check flags at the common
helper function.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Missing semicolon at the end of macros can confuse some analyzers
(like cppcheck <filename>), and we have a mix of semicolon and
non-semicolon usage through the code. Let's standardize on using
a semicolon for VIR_ENUM_DECL calls.

Drop the semicolon from the final statement of the macro, so
the compiler will require callers to add a semicolon.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This is essentially a wrapper for easily setting the variable
name in virDomainDeviceDef that matches its associated
VIR_DOMAIN_DEVICE_TYPE.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This will be extended in the future, so let's simplify things by
centralizing the checks.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

A helper function for allocating the virDomainGraphicsDef structure.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The 'readonly' option allows users to mark vNVDIMM read-only:

<devices>
  ...
  <memory model='nvdimm' access='shared'>
      <source>
          <path>/dev/dax0.0</path>
      </source>
      <target>
          <size unit='MiB'>4094</size>
          <node>0</node>
          <label>
              <size unit='MiB'>2</size>
          </label>
          <readonly/>
      </target>
  </memory>
  ...
</devices>
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The 'pmem' option allows users to specify whether the backend
storage of memory-backend-file is a real persistent memory:

<devices>
  ...
  <memory model='nvdimm' access='shared'>
      <source>
          <path>/dev/dax0.0</path>
          <pmem/>
      </source>
      <target>
          <size unit='MiB'>4094</size>
          <node>0</node>
          <label>
              <size unit='MiB'>2</size>
          </label>
      </target>
  </memory>
  ...
</devices>
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

NVDIMM emulation will mmap the backend file, it uses host pagesize
as the alignment of mapping address before, but some backends may
require alignments different from the pagesize. So the 'alignsize'
option is introduced to allow specification of the proper alignment:

<devices>
  ...
  <memory model='nvdimm' access='shared'>
      <source>
          <path>/dev/dax0.0</path>
          <alignsize unit='MiB'>2</alignsize>
      </source>
      <target>
          <size unit='MiB'>4094</size>
          <node>0</node>
          <label>
              <size unit='MiB'>2</size>
          </label>
      </target>
  </memory>
  ...
</devices>
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Require that all headers are guarded by a symbol named

  LIBVIRT_$FILENAME

where $FILENAME is the uppercased filename, with all characters
outside a-z changed into '_'.

Note we do not use a leading __ because that is technically a
namespace reserved for the toolchain.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

In many files there are header comments that contain an Author:
statement, supposedly reflecting who originally wrote the code.
In a large collaborative project like libvirt, any non-trivial
file will have been modified by a large number of different
contributors. IOW, the Author: comments are quickly out of date,
omitting people who have made significant contribitions.

In some places Author: lines have been added despite the person
merely being responsible for creating the file by moving existing
code out of another file. IOW, the Author: lines give an incorrect
record of authorship.

With this all in mind, the comments are useless as a means to identify
who to talk to about code in a particular file. Contributors will always
be better off using 'git log' and 'git blame' if they need to  find the
author of a particular bit of code.

This commit thus deletes all Author: comments from the source and adds
a rule to prevent them reappearing.

The Copyright headers are similarly misleading and inaccurate, however,
we cannot delete these as they have legal meaning, despite being largely
inaccurate. In addition only the copyright holder is permitted to change
their respective copyright statement.
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Since we need to specify the rendernode option onto QEMU cmdline, we
need this union member to retain consistency in how we build the
cmdline.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

A few simple helpers that allow us to determine whether a graphics can
and will need to make use of a DRM render node.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Since this is something between PV and HVM, it makes sense to put the
setting in place where domain type is specified.
To enable it, use <os><type machine="xenpvh">xenpvh</type></os>. It is
also included in capabilities.xml, for every supported HVM guest type - it
doesn't seems to be any other requirement (besides new enough Xen).
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

Add a new memoryBacking source type "memfd", supported by QEMU (when
the capability is available).

A memfd is a specialized anonymous memory kind. As such, an anonymous
source type could be automatically using a memfd. However, there are
some complications when migrating from different memory backends in
qemu (mainly due to the internal object naming at this point, but
there could be more). For now, it is simpler and safer to simply
introduce a new source type "memfd". Eventually, the "anonymous" type
could learn to use memfd transparently in a separate change.

The main benefits are that it doesn't need to create filesystem files,
and it also enforces sealing, providing a bit more safety.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Support Hyper-V Enlightened VMCS in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_EVMCS
cases to src/qemu/* for now.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

Support Hyper-V PV IPI enlightenment in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI
cases to src/qemu/* for now.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

Introducing <monitor> element under <cachetune> to represent
a cache monitor.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since its introduction in commit 2e37bf42 the naming of the arguments
between the prototype and the definition does not match.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The function is called on a virDomainDeviceInfo, so it
should be declared along with it.

Moving this function requires moving and making public
virDomainDeviceCCWAddressIsValid() as well, but that's
perfectly fine since the same reasoning above also
applies to it, due to virDomainDeviceCCWAddress being
(correctly) declared in device_conf.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's used in virDomainDeviceInfo, which makes
domain_conf the wrong place to declare it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

None of the existing models is suitable for use with
RISC-V virt guests, and we don't want information about
the serial console to be missing from the XML.

The name is based on comments in qemu/hw/riscv/virt.c:

  RISC-V machine with 16550a UART and VirtIO MMIO

and in qemu/hw/char/serial.c:

  QEMU 16550A UART emulation

along with the output of dmesg in the guest:

  Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
  10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
    base_baud= 230400) is a 16550A
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Allow storing of private data in the status XML for disks.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Qemu-3.0 supports Hyper-V-style PV TLB flush, Windows guests can benefit
from this feature as KVM knows which vCPUs are not currently scheduled (and
thus don't require any immediate action).
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Qemu-3.0 supports so-called 'Reenlightenment' notifications and this (in
conjunction with 'hv-frequencies') can be used make Hyper-V on KVM pass
stable TSC page clocksource to L2 guests.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Qemu-2.12 gained 'hv-frequencies' cpu flag to enable Hyper-V frequency
MSRs. These MSRs are required (but not sufficient) to make Hyper-V on
KVM pass stable TSC page clocksource to L2 guests.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Resctrl not only supports cache tuning, but also memory bandwidth
tuning. Renaming cachetune to resctrl to reflect that. With resctrl,
all allocation for different resources (cache, memory bandwidth) are
aggregated and represented by a virResctrlAllocPtr inside
virDomainResctrlDef.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Use of enum types for struct fields is generally avoided since it causes
warnings if the compiler assumes the enum is unsigned. For example

  commit 8e2982b5
  Author: Cole Robinson <crobinso@redhat.com>
  Date:   Tue Jul 24 16:27:54 2018 -0400

    conf: Clean up virDomainDefParseCaps

Introduced a line:

  if ((def->virtType = virDomainVirtTypeFromString(virttype)) < 0) {

which causes a build failure with CLang

  conf/domain_conf.c:19143:65: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare]

as the compiler is free to optimize away the "< 0" check due to the
assumption that the enum type is unsigned and always in range.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

SKIP_OSTYPE_CHECKS only hides some error reporting at this point,
so it can be foled into SKIP_VALIDATE
Acked-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Historically, we've always enabled an emulated video device every time we
see that graphics should be supported with a guest. With the appearance
of mediated devices which can support QEMU's vfio-display capability,
users might want to use such a device as the only video device.
Therefore introduce a new, effectively a 'disable', type for video
device.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

QEMU 2.12 introduced a new type of display for mediated devices using
vfio-pci backend which allows a mediated device to be used as a VGA
compatible device as an alternative to an emulated video device. QEMU
exposes this feature via a vfio device property 'display' with supported
values 'on/off/auto' (libvirt will default to 'off').

This patch adds the necessary bits to domain config handling in order to
expose this feature. Since there's no convenient way for libvirt to come
up with usable defaults for the display setting, simply because libvirt
is not able to figure out which of the display implementations - dma-buf
which requires OpenGL support vs vfio regions which doesn't need OpenGL
(works with OpenGL enabled too) - the underlying mdev uses.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

A simple helper which will loop through all the graphics elements and
checks whether at least one of them enables OpenGL support, either by
containing <gl enable='yes'/> or being of type 'egl-headless'.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since 2.10 QEMU supports a new display type egl-headless which uses the
drm nodes for OpenGL rendering copying back the rendered bits back to
QEMU into a dma-buf which can be accessed by standard "display" apps
like VNC or SPICE. Although this display type can be used on its own,
for any practical use case it makes sense to pair it with either VNC or
SPICE display. The clear benefit of this display is that VNC gains
OpenGL support, which it natively doesn't have, and SPICE gains remote
OpenGL support (native OpenGL support only works locally through a UNIX
socket, i.e. listen type=socket/none).
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

There wasn't an explicit type case to the video type enum in
qemuDomainDeviceDefValidateVideo, _TYPE_GOP was also missing from the
switch.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Future patches rely on the ability to reset the contents of the
virDomainVideoDef structure rather than re-allocating it.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

When updating a live device users might pass different alias than
the one the device has. Currently, this is silently ignored which
goes against our behaviour for other parts of the device where we
explicitly allow only certain changes and error out loudly on
anything else.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This was lost in c57f3fd2. But now we are going to
need it again (except the DETACH action where checking for device
compatibility does not make much sense anyway).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>