Accept a new driver name attribute to specify usage of helper process, ex:

  <video>
    <driver name='vhostuser'/>
    <model type='virtio'/>
  </video>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Although <interface type='ethernet'> has always been able to use an
existing tap device, this is just a coincidence due to the fact that
the same ioctl is used to create a new tap device or get a handle to
an existing device.

Even then, once we have the handle to the device, we still insist on
doing extra setup to it (setting the MAC address and IFF_UP).  That
*might* be okay if libvirtd is running as a privileged process, but if
libvirtd is running as an unprivileged user, those attempted
modifications to the tap device will fail (yes, even if the tap is set
to be owned by the user running libvirtd). We could avoid this if we
knew that the device already existed, but as stated above, an existing
device and new device are both accessed in the same manner, and
anyway, we need to preserve existing behavior for those who are
already using pre-existing devices with privileged libvirtd (and
allowing/expecting libvirt to configure the pre-existing device).

In order to cleanly support the idea of using a pre-existing and
pre-configured tap device, this patch introduces a new optional
attribute "managed" for the interface <target> element. This
attribute is only valid for <interface type='ethernet'> (since all
other interface types have mandatory config that doesn't apply in the
case where we expect the tap device to be setup before we
get it). The syntax would look something like this:

   <interface type='ethernet'>
      <target dev='mytap0' managed='no'/>
      ...
   </interface>

This patch just adds managed to the grammar and parser for <target>,
but has no functionality behind it.

(NB: when managed='no' (the default when not specified is 'yes'), the
target dev is always a name explicitly provided, so we don't
auto-remove it from the config just because it starts with "vnet"
(VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the
same pattern of names that libvirt itself uses when it automatically
creates the tap devices.)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Support 'Direct Mode' for Hyper-V Synthetic Timers in domain config.
Make it 'stimer' enlightenment option as it is not a separate thing.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

QEMU version 2.12.1 introduced a performance feature under commit
be7773268d98 ("target-i386: add KVM_HINTS_DEDICATED performance hint")

This patch adds a new KVM feature 'hint-dedicated' to set this performance
hint for KVM guests. The feature is off by default.

To enable this hint and have libvirt add "-cpu host,kvm-hint-dedicated=on"
to the QEMU command line, the following XML code needs to be added to the
guest's domain description in conjunction with CPU mode='host-passthrough'.

  <features>
    <kvm>
      <hint-dedicated state='on'/>
    </kvm>
  </features>
  ...
  <cpu mode='host-passthrough ... />
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
Signed-off-by: NMenno Lageman <menno.lageman@oracle.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

host-passthrough documentation menions that the source and destination
hosts are not identical in both hardware and configuration.  Configuration
actually includes microcode version and QEMU version, but this is not
clear so make it explicit
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190802125415.15227-1-pbonzini@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Introduced by: commit e9528f41

'msrs' is a feature unrelated to Hyper-V Enlightenments, the commit message
which added it and the test have it right:

    <features>
      ...
      <msrs unknown='ignore'>
      ...
    </features>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

SynIC stands for 'Synthetic Interrupt Controller', it is not a NIC. Fix the
spelling in accordance with Hypervisor Top Level Functional Specification.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The example XML we have contains all other Hyper-V Enlightenments but
'stimer' is missing.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Describe the encryption element in the TPM's domain XML.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

As of commit 7373c4e4 the QEMU driver also supports TSC.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Update schema and configuration to allow specifying new video type of
'bochs'. Add implementation and tests for qemu.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

We support pcie-to-pci-bridge, and prefer it to
dmi-to-pci-bridge, since libvirt 4.3.0, but we didn't
update all the documentation accordingly at the time.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The portid will be the UUID of the virNetworkPort object associated
with the network interface when a guest is running.
Reviewed-by: NLaine Stump <laine@laine.org>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

SMMUv3 is an IOMMU implementation for ARM virt guests.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Although there's currently only support for SEV, it's likely other
solutions will appear, so we should not refer to the documentation
section simply with 'sev'.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

firmware attribute from <os/> takes either 'efi' or 'bios' as its
allowed values. However, the current documentation mistakenly mentions
'uefi' instead of 'efi'.
Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Just one missing occurrence of iothreadsched fixed plus some rewording for this
to make more sense for the readers.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

xenbus is virtual controller (akin to virtio controllers) for Xen
paravirtual devices. Although all Xen VMs have a xenbus, it has
never been modeled in libvirt, or in Xen native VM config format
for that matter.

Recently there have been requests to support Xen's max_grant_frames
setting in libvirt. max_grant_frames is best modeled as an attribute
of xenbus. It describes the maximum IO buffer space (or DMA space)
available in xenbus for use by connected paravirtual devices. This
patch introduces a new xenbus controller type that includes a
maxGrantFrames attribute.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The idea is that using this attribute users enable libvirt to
automagically select firmware image for their domain. For
instance:

  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
    <loader secure='no'/>
  </os>

  <os firmware='bios'>
    <type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
  </os>

(The automagic of selecting firmware image will be described in
later commits.)

Accepted values are 'bios' and 'efi' to let libvirt select
corresponding type of firmware.

I know it is a good sign to introduce xml2xml test case when
changing XML config parser but that will have to come later.
Firmware auto selection is not enabled for any driver just yet so
any xml2xml test would fail right away.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Some devices (namely virtio-scsi, virtio-gpu, virtio-keyboard,
virtio-tablet and virtio-mouse, plus virtio-crypto which is
not supported by libvirt) don't follow the same rules as all
other virtio devices, which is something that ought to be
documented.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

virtio-(non-)transitional device models have been introduced
in 5.2.0, not 5.1.0.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Add <controller type='scsi' model handling for virtio transitional
devices. Ex:

  <controller type='scsi' model='virtio-transitional'/>

* "virtio-transitional" maps to qemu "virtio-scsi-pci-transitional"
* "virtio-non-transitional" maps to qemu "virtio-scsi-non-transitional"

The naming here doesn't match the pre-existing model=virtio-scsi.
The prescence of '-scsi' there seems kind of redundant as we have
type='scsi' already, so I decided to follow the pattern of other
patches and use virtio-transitional etc.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Add controller type='virtio-serial' model handling for virtio
transitional devices. Ex:

  <controller type='virtio-serial' model='virtio-transitional'/>

* "virtio-transitional" maps to qemu "virtio-serial-pci-transitional"
* "virtio-non-transitional" maps to qemu "virtio-serial-pci-non-transitional"
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

<input> devices lack the model= attribute which is used by
most other device types. To eventually support
virtio-input-host-pci-{non-}traditional in qemu, let's add
a standard model= attribute. This just adds the domain_conf
wiring
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Add <vsock> model handling for virtio transitional devices. Ex:

  <vsock model='virtio-transitional'>
    ...
  </vsock>

* "virtio-transitional" maps to qemu "vhost-vsock-pci-transitional"
* "virtio-non-transitional" maps to qemu "vhost-vsock-pci-non-transitional"
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Add new <memballoon> model values for virtio transitional devices. Ex:

  <memballoon model='virtio-transitional'/>

* "virtio-transitional" maps to qemu "virtio-balloon-pci-transitional"
* "virtio-non-transitional" maps to qemu "virtio-balloon-pci-non-transitional"
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

<filesystem> devices lack the model= attribute which is used by
most other device types. To eventually support
virtio-9p-pci-{non-}traditional in qemu, let's add a standard
model= attribute. The accepted values are:

- virtio
- virtio-transitional
- virtio-non-transitional
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Add new <rng> model values for virtio transitional devices. Ex:

  <rng model='virtio-transitional'>
    ...
  </rng>

* "virtio-transitional" maps to qemu "virtio-rng-pci-transitional"
* "virtio-non-transitional" maps to qemu "virtio-rng-pci-non-transitional"
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

qemu vhost-scsi devices map to XML roughly like:

    <hostdev mode='subsystem' type='scsi_host'>
      <source protocol='vhost' wwpn=X/>
    </hostdev>

To support vhost-scsi-pci-{non-}traditional in qemu, we
need to to extend the SCSI Host hostdev XML to handle
model= value. This matches the XML model= format used
for mediated devices. This is just the domain_conf bits
and some XML test cases.

Use of virtio-X naming here does not match the hostdev
protocol=vhost nor does it match the qemu vhost-X device
naming, however it's more consistent with all other
model= names in this area, and also matches the
inconsistency of <vsock> devices which use model=virtio
but map to vhost-vsock on the qemu commandline
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Add new <interface> model handling for virtio transitional devices. Ex:

<interface>
  <model type='virtio-transitional'/>
</interface>

* "virtio-transitional" maps to qemu "virtio-net-pci-transitional"
* "virtio-non-transitional" maps to qemu "virtio-net-pci-non-transitional"
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

<disk> devices lack the model= attribute which is used by
most other device types. bus= mostly acts as one, but it
serves other purposes too like determing what target=
prefix to use, and for matching against controller type=
values.

Extending bus= to handle additional virtio transitional
devices will complicate apps lives, and it isn't a clean
mapping anyways. So let's bite the bullet and add a new
<disk model=X/> attribute, and wire up common handling
for virtio and virtio-{non-}transitional
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Implement the MSRs ignore unknown reads and writes feature
that's specified using:

  <features>
    ...
    <msrs unknown='ignore'>
    ...
  </features>

in the domain XML.

In bhyve, it's just passing '-w' command line argument to the bhyve(8)
executable.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

We dropped support in commit 8e91a400 (November 2015), but some
occurrences still remained, even in live code.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reported-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Luckily, the new URL still points to the same location, the only change
is in the document name where an escaped space (%20) was replaced by an
underscore.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@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>