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>

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.

This element will control secure boot implemented by some
firmwares. If the firmware used in <loader/> does support the
feature we must tell it to the underlying hypervisor. However, we
can't know whether loader does support it or not just by looking
at the file. Therefore we have to have an attribute to the
element where users can tell us whether the firmware is secure
boot enabled or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Add the definitions to allow for viewing/setting cgroup period and quota
limits for IOThreads.

This is similar to the work done for emulator quota and period by
commit ids 'b65dafa8' and 'e051c482'.

Being able to view/set the IOThread specific values is related to more
recent changes adding global period (commmit id '4d92d58f') and global
quota (commit id '55ecdae0') definitions and qemu support (commit id
'4e17ff79' and 'fbcbd1b2'). With a global setting though, if somehow
the IOThread value in the cgroup hierarchy was set "outside of libvirt"
to a value that is incompatible with the global value.

Allowing control over IOThread specific values provides the capability
to alter the IOThread values as necessary.

According to libxl implementation, it supports pvusb
controller of version 1.1 and version 2.0, and it
supports two types of backend, 'pvusb' (dom0 backend)
and 'qusb' (qemu backend). But currently pvusb backend
is not checked in yet.

To match libxl support, extend usb controller schema
to support two more models: qusb1 (qusb, version 1.1)
and 'qusb2' (qusb version 2.0).
Signed-off-by: NChunyan Liu <cyliu@suse.com>

  This patch reflects cases when <interface> element and its <source>
subelement for network type are formated based on actual type resolved
from referenced network instead of original one. networkAllocateActualDevice
and virDomainActualNetDefContentsFormat are taken as reference.

We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).

Only format the port if it has been specified and mark it as optional
in the XML schema.

A device with an attribute 'model', with just one model
so far:

<devices>
  ...
  <iommu model='intel'/>
</devices>

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

This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:

    <interface type='ethernet'>
      <mac address='00:16:3e:0f:ef:8a'/>
      <source>
        <ip address='192.168.122.12' family='ipv4'
            prefix='24' peer='192.168.122.1'/>
        <ip address='192.168.122.13' family='ipv4' prefix='24'/>
        <route family='ipv4' address='0.0.0.0'
               gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.124.0' prefix='24'
               gateway='192.168.124.1'/>
      </source>
    </interface>

In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).

(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).

(This patch had been pushed earlier in
commit fe6a7789, but was reverted in
commit d6584565 because it had been
accidentally pushed during the freeze for release 2.0.0)

The peer attribute is used to set the property of the same name in the
interface IP info:

  <interface type='ethernet'>
    ...
    <ip family='ipv4' address='192.168.122.5'
        prefix='32' peer='192.168.122.6'/>
    ...
  </interface>

Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.

(This patch now has quite a history: it was originally pushed in
commit 690969af, which was subsequently reverted in commit 1d14b13f,
then reworked and pushed (along with a lot of other related/supporting
patches) in commit 93135abf; however *that* commit had been
accidentally pushed during dev. freeze for release 2.0.0, so it was
again reverted in commit f6acf039).
Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: NLaine Stump <laine@laine.org>

    This replicates the metadata field found in the domain configuration
    and adds it to the network configuration XML.

This reverts commit 93135abf.

This feature was accidentally pushed in the feature freeze.

This reverts commit fe6a7789.

This feature was accidentally pushed in the feature freeze.

This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:

    <interface type='ethernet'>
      <mac address='00:16:3e:0f:ef:8a'/>
      <source>
        <ip address='192.168.122.12' family='ipv4'
            prefix='24' peer='192.168.122.1'/>
        <ip address='192.168.122.13' family='ipv4' prefix='24'/>
        <route family='ipv4' address='0.0.0.0'
               gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.124.0' prefix='24'
               gateway='192.168.124.1'/>
      </source>
    </interface>

In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types, and 2) we can retain the info when set to
an invalid interface type all the way through to validation and report
a proper error, rather than just ignoring it (which is currently what
happens for many other type-specific settings).

(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).

The peer attribute is used to set the property of the same name in the
interface IP info:

  <interface type='ethernet'>
    ...
    <ip family='ipv4' address='192.168.122.5'
        prefix='32' peer='192.168.122.6'/>
    ...
  </interface>

Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.

(This is an updated *re*-commit of commit 690969af, which was
subsequently reverted in commit 1d14b13f).
Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: NLaine Stump <laine@laine.org>

All the same information was already there, just in slightly different
places in the virDomainNetDef.

a.k.a. <hostdev mode='capabilities' type='net'>.

This replaces the existing nips, ips, nroutes, and routes with a
single virNetDevIPInfo, and simplifies the code by calling that
object's parse/format/clear functions instead of open coding.

There are currently two places in the domain where this combination is
used, and there is about to be another. This patch puts them together
for brevity and uniformity.

As with the newly-renamed virNetDevIPAddr and virNetDevIPRoute
objects, the new virNetDevIPInfo object will need to be accessed by a
utility function that calls low level Netlink functions (so we don't
want it to be in the conf directory) and will be called from multiple
hypervisor drivers (so it can't be in any hypervisor directory); the
most appropriate place is thus once again the util directory.

The parse and format functions are in conf/domain_conf.c because only
the domain XML (i.e. *not* the network XML) has this exact combination
of IP addresses plus routes. Note that virDomainNetIPInfoFormat() will
end up being the only caller to virDomainNetRoutesFormat() and
virDomainNetIPsFormat(), so it will just subsume those functions in a
later patch, but we can't do that until they are no longer called.

(It would have been nice to include the interface name within the
virNetDevIPInfo object (with a slight name change), but that can't
be done cleanly, because in each case the interface name is provided
in a different place in the XML relative to the routes and IP
addresses, so putting it in this object would actually make the code
more confused rather than simpler).

When support for <interface type='ethernet'> was added in commit
9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
for a user-specified guest-side interface name. This was never
documented though. (that attribute already existed at the time in the
data.ethernet union member of virDomainNetDef, but apparently had no
practical use - it was only used as a storage place for a NetDef's
bridge name during qemuDomainXMLToNative(), but even then that was
never used for anything).

When support for similar guest-side device naming was added to the lxc
driver several years later, it was put in a new subelement <guest
dev='blah'/>.

In the intervening years, since there was no validation that
ethernet.dev was NULL in the other drivers that didn't actually use
it, innocent souls who were adding other features assuming they needed
to account for non-NULL ethernet.dev when really they didn't, so
little bits of the usual pointless cargo-cult code showed up.

This patch not only switches the openvz driver to use the documented
<guest dev='blah'/> notation for naming the guest-side device (just in
case anyone is still using the openvz driver), and logs an error if
anyone tries to set <source dev='blah'/> for a type='ethernet'
interface, it also removes the cargo-cult uses of ethernet.dev and
<source dev='blah'/>, and eliminates if from the RNG and from
virDomainNetDef.

NB: I decided on this course of action after mentioning the
inconsistency here:

  https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html

and getting encouragement do eliminate it in a later IRC discussion
with danpb.

There was no documentation at all for the XML part. I added at least
some. The 2.0.0 introduction date is deliberate as the parser for the
XML is broken.

The schema file was missing entries for 'mbml' and 'mbmt'.

This option allows or disallows detection of zero-writes if it is set to
"on" or "off", respectively.  It can be also set to "unmap" in which
case it will try discarding that part of image based on the value of the
"discard" option.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This new listen type is currently supported only by spice graphics.
It's introduced to make it easier and clearer specify to not listen
anywhere in order to start a guest with OpenGL support.

The old way to do this was set spice graphics autoport='no' and don't
specify any ports.  The new way is to use <listen type='none'/>.  In
order to be able to migrate to old libvirt the migratable XML will be
generated without the listen element and with autoport='no'.  Also the
old configuration will be automatically converted to the this listen
type.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

Hand-entering indexes for 20 PCI controllers is not as tedious as
manually determining and entering their PCI addresses, but it's still
annoying, and the algorithm for determining the proper index is
incredibly simple (in all cases except one) - just pick the lowest
unused index.

The one exception is USB2 controllers because multiple controllers in
the same group have the same index. For these we look to see if 1) the
most recently added USB controller is also a USB2 controller, and 2)
the group *that* controller belongs to doesn't yet have a controller
of the exact model we're just now adding - if both are true, the new
controller gets the same index, but in all other cases we just assign
the lowest unused index.

With this patch in place and combined with the automatic PCI address
assignment, we can define a PCIe switch with several ports like this:

  <controller type='pci' model='pcie-root-port'/>
  <controller type='pci' model='pcie-switch-upstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  ...

These will each get a unique index, and PCI addresses that connect
them together appropriately with no pesky numbers required.

Add a new element to <domain> XML:
<os>
  <acpi>
    <table type="slic">/path/to/acpi/table/file</table>
  </acpi>
</os>

To supply a path to a SLIC (Software Licensing) ACPI
table blob.

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

We support omitting listen attribute of graphics element so we should
also support omitting address attribute of listen element.  This patch
also updates libvirt to always add a listen element into domain XML
except for VNC graphics if socket attribute is specified.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add the ability to add an 'iothread' to the controller which will be how
virtio-scsi-pci and virtio-scsi-ccw iothreads have been implemented in qemu.

Describe the new functionality and add tests to parse/validate that the
new attribute can be added.

This adds a ports= attribute to usb controller XML, like

  <controller type='usb' model='nec-xhci' ports='8'/>

This maps to:

  qemu -device nec-usb-xhci,p2=8,p3=8

Meaning, 8 ports that support both usb2 and usb3 devices. Gerd
suggested to just expose them as one knob.

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

If a panic device is being defined without a model in a domain
the default value is always overwritten with model ISA. An ISA
bus does not exist on S390 and therefore specifying a panic device
results in an unsupported configuration.
Since the S390 architecture inherently provides a crash detection
capability the panic device should be defined in the domain xml.

This patch adds an s390 panic device model and prevents setting a
device address on it.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

This reverts commit 690969af, which
added the domain config parts to support a "peer" attribute in domain
interface <ip> elements.

It's being removed temporarily for the release of libvirt 1.3.4
because the feature doesn't work, and there are concerns that it may
need to be modified in an externally visible manner which could create
backward compatibility problems.

Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45

However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:

http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html

Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely

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

The hex range already tried to allow for it, but it wasn't using
the correct XML hex syntax. Fix it, and test it

This controller provides a single PCIe port on a new root. It is
similar to pci-expander-bus, intended to provide a bus that can be
associated with a guest-identifiable NUMA node, but is for
machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).

Aside from PCIe vs. PCI, the other main difference is that a
pci-expander-bus has a companion pci-bridge that is automatically
attached along with it, but pcie-expander-bus has only a single port,
and that port will only connect to a pcie-root-port, or to a
pcie-switch-upstream-port. In order for the bus to be of any use in
the guest, it must have either a pcie-root-port or a
pcie-switch-upstream-port attached (and one or more
pcie-switch-downstream-ports attached to the
pcie-switch-upstream-port).

This is a standard PCI root bus (not a bridge) that can be added to a
440fx-based domain. Although it uses a PCI slot, this is *not* how it
is connected into the PCI bus hierarchy, but is only used for
control. Each pci-expander-bus provides 32 slots (0-31) that can
accept hotplug of standard PCI devices.

The usefulness of pci-expander-bus relative to a pci-bridge is that
the NUMA node of the bus can be specified with the <node> subelement
of <target>. This gives guest-side visibility to the NUMA node of
attached devices (presuming that management apps only assign a device
to a bus that has a NUMA node number matching the node number of the
device on the host).

Each pci-expander-bus also has a "busNr" attribute. The expander-bus
itself will take the busNr specified, and all buses that are connected
to this bus (including the pci-bridge that is automatically added to
any expander bus of model "pxb" (see the next commit)) will use
busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
lower busNr) will use bus numbers lower than busNr.

nwfilter.rng defines uint16range and uint32range, but in a different
manner (it also allows a variable name as the value, rather than just
a decimal or hex number). I wanted to add uint16range to
basictypes.rng, but my desired definition was parallel to those for
uint8range and uint24range which are defined in basictypes.rng - they
*don't* allow a variable name for the value.

The simplest path to make everyone happy is to make the "plain"
versions in basictypes.rng have simpler names - "uint8", "uint16", and
"uint24". This patch renames uint8range and uint24range to uint8 and
uint24, while the next patch will add uint16.

Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>

This patch adds new xml element, and so we can have the option of
also having perf events enabled immediately at startup.
Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>
Message-id: 1459171833-26416-6-git-send-email-qiaowei.ren@intel.com