Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

Introduce a 'managed' attribute to allow libvirt to decide whether to
delete a vHBA vport created via external means such as nodedev-create.
The code currently decides whether to delete the vHBA based solely on
whether the parent was provided at creation time. However, that may not
be the desired action, so rather than delete and force someone to create
another vHBA via an additional nodedev-create allow the configuration of
the storage pool to decide the desired action.

During createVport when libvirt does the VPORT_CREATE, set the managed
value to YES if not already set to indicate to the deleteVport code that
it should delete the vHBA when the pool is destroyed.

If libvirtd is restarted all the memory only state was lost, so for a
persistent storage pool, use the virStoragePoolSaveConfig in order to
write out the managed value.

Because we're now saving the current configuration, we need to be sure
to not save the parent in the output XML if it was undefined at start.
Saving the name would cause future starts to always use the same parent
which is not the expected result when not providing a parent. By not
providing a parent, libvirt is expected to find the best available
vHBA port for each subsequent (re)start.

At deleteVport, use the new managed value to decide whether to execute
the VPORT_DELETE.  Since we no longer save the parent in memory or in
XML when provided, if it was not provided, then we have to look it up.

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

Introduce the ability to save a configuration of a persistent configuration
that may be changed by storage pool backend activity, such as start or stop

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

Passing a copy of the storage pool adapter to a function just changes the
copy of the fields in the particular function and then when returning to
the caller those changes are discarded.  While not yet biting us in the
storage clean-up case, it did cause an issue for the fchost storage pool
startup case, createVport.  The issue was at startup, if no parent is found
in the XML, the code will search for the 'best available' parent and then
store that in the in memory copy of the adapter.  Of course, in this case
it was a copy, so when returning to the virStorageBackendSCSIStartPool that
change was discarded (or lost) from the pool->def->source.adapter which
meant at shutdown (deleteVport), the code assumed no adapter was passed
and skipped the deletion, leaving the vHBA created by libvirt still defined
requiring an additional stop of a nodedev-destroy to remove.

Adjusted the createVport to take virStoragePoolDefPtr instead of the
adapter copy. Then use the virStoragePoolSourceAdapterPtr when processing.
A future patch will need the 'def' anyway, so this just sets up for that.

virDomainChrSourceDefIsEqual should return 'true' for
identical SPICEVMC chardevs, and those that have no source
specification.

After this change, a failed hotplug no longer leaves a stale
pointer in the domain definition.

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

Modify the structure _virDomainBlockIoTuneInfo to support these the new
options.
Change the initialization of the variable expectedInfo in qemumonitorjsontest.c
to avoid compiling problem.
Add documentation about the new xml options
Signed-off-by: NMatthias Gatto <matthias.gatto@outscale.com>

CPU numa topology implicitly allows memory specification in 'KiB'.

Enabling this to accept the 'unit' in which memory needs to be specified.
This now allows users to specify memory in units of choice, and
lists the same in 'KiB' -- just like other 'memory' elements in XML.

    <numa>
      <cell cpus='0-3' memory='1024' unit='MiB' />
      <cell cpus='4-7' memory='1024' unit='MiB' />
    </numa>

Also augment test cases to correctly model NUMA memory specification.
This adds the tag 'unit="KiB"' for memory attribute in NUMA cells.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 01b4de2b abstracts virDomainParseMemory()
for use by other functions in domain_conf.c
Extend the same for use, for functions outside of this file.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As reviewing patches upstream it occurred to me, that we have two
functions doing nearly the same: virDomainParseMemory which
expects XML in the following format:

  <memory unit='MiB'>1337</memory>

The other function being virDomainHugepagesParseXML expecting the
following format:

  <someElement size='1337' unit='MiB'/>

It wouldn't matter to have two functions handle two different
scenarios like this if we could only not copy code that handles
32bit arches around. So this code merges the common parts into
one by inventing new @units_xpath argument to
virDomainParseMemory which allows overriding the default location
of @unit attribute in XML. With this change both scenarios above
can be parsed with virDomainParseMemory.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

PowerISA allows processors to run VMs in binary compatibility ("compat")
mode supporting an older version of ISA. QEMU has recently added support to
explicitly denote a VM running in compatibility mode through commit 6d9412ea
& 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu
commandline on a POWER8 host:  -cpu host,compat=power7.

This patch allows libvirt to exploit cpu mode 'host-model' to describe this
new mode for PowerKVM guests. For example, when a user wants to request a
power7 vm to run in compatibility mode on a Power8 host, this can be
described in XML as follows :

  <cpu mode='host-model'>
    <model>power7</model>
  </cpu>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

This adds support for PowerPC Little Endian architecture.,
and allows libvirt to spawn VMs based on 'ppc64le' architecture.
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This is a reaction to Michal's fix [1] for non-NUMA systems that also
splits out conf/ out of util/ because libvirt_util shouldn't require
libvirt_conf if it is the other way around.  This particular use case
worked, but we're trying to avoid it as mentioned [2], many times.

The only functions from virnuma.c that needed numatune_conf were
virDomainNumatuneNodesetIsAvailable() and virNumaSetupMemoryPolicy().
The first one should be in numatune_conf as it works with
virDomainNumatune, the second one just needs nodeset and mode, both of
which can be passed without the need of numatune_conf.

Apart from fixing that, this patch also fixes recently added
code (between commits d2460f85^..5c851562) that doesn't support
non-contiguous nodesets.  It uses new function
virNumaNodesetIsAvailable(), which doesn't need a stub as it doesn't use
any libnuma functions, to check if every specified nodeset is available.

[1] https://www.redhat.com/archives/libvir-list/2014-November/msg00118.html
[2] http://www.redhat.com/archives/libvir-list/2011-June/msg01040.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

Domain memory elements such as max_balloon and cur_balloon are
implemented as 'unsigned long long', whereas the 'memory' element
in NUMA cells is implemented as 'unsigned int'.

Use the same data type (unsigned long long) for 'memory' element
in NUMA cells.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>

There was no check for 'nodeset' attribute in numatune-related
elements.  This patch adds validation that any nodeset specified does
not exceed maximum host node.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>

Since commit 3f99d64d no new scsi_host pools can be defined
if one of the already defined scsi_host pools does not refer
to an accessible scsi_host adapter.

Relax the check by skipping over these inaccessible pools
when checking for duplicates.

If both source adapters are specified by a parent address,
just comparing the address is faster and catches even addresses
that do not refer to valid adapters.

Commit 6c9a8a49 (Oct 2014) exposed a long-standing issue on 32-bit
machines: code related to virDomainSetMemoryParameters has always
been documented as using a 64-bit limit, but it was implemented by
calling virDomainParseMemory which enforced an 'unsigned long'
limit.  Since VIR_DOMAIN_MEMORY_PARAM_UNLIMITED capped to a
long is -1, but virDomainParseScaledValue no longer accepts
negative values, an attempt to use 2^53-1 as a hard memory limit
started failing the testsuite.  However, the problem with capping
things artificially low has existed for much longer - ever since
commits 4888f0fb and 2e22f23b (Mar 2012) switched internal tracking
from 'unsigned long' to 'unsigned long long' (prior to that time,
the cap was a side-effect of the choice of types).  We _have_ to
cap the balloon memory values, (no thanks to baked in 'unsigned long'
of API such as virDomainSetMaxMemory or virDomainGetInfo with no
counterpart API that guarantees 64-bit access to those numbers)
but memory parameters have never needed the artificial limit.

At any rate, the solution is to make the parser function gain a
parameter, and only do the reduced 32-bit cap for the values that
are constrained due to API.

* src/conf/domain_conf.h (_virDomainMemtune): Add comments.
* src/conf/domain_conf.c (virDomainParseMemory): Add parameter.
(virDomainDefParseXML): Adjust callers.
Signed-off-by: NEric Blake <eblake@redhat.com>

It makes sense for none of the callers to have negative value as an
output and, fortunately, if anyone tried defining domain with negative
memory or any other value parsed by virDomainParseScaledValue(), the
resulting value was 0.  That means we can error out during parsing as
it won't break anything.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1155843Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

C guarantees that static variables are zero-initialized.  Some older
compilers (and also gcc -fno-zero-initialized-in-bss) create larger
binaries if you explicitly zero-initialize a static variable.

* src/conf/nwfilter_conf.c: Fix initialization.
* src/cpu/cpu_x86.c: Likewise.
* src/interface/interface_backend_netcf.c: Likewise.
* src/locking/lock_daemon.c: Likewise.
* src/locking/lock_driver_lockd.c: Likewise.
* src/locking/lock_driver_sanlock.c: Likewise.
* src/network/bridge_driver.c: Likewise.
* src/node_device/node_device_udev.c: Likewise.
* src/nwfilter/nwfilter_learnipaddr.c: Likewise.
* src/rpc/virnetserver.c: Likewise.
* src/security/security_selinux.c
(virSecuritySELinuxGenSecurityLabel): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

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

Resolve a crash in libvirtd resulting from commit id 'a4bd62ad' (1.0.6)
which added parentaddr and unique_id to allow unique identification of
a scsi_host, but assumed that all the pool entries and the incoming
definition would be similarly defined. If the existing pool uses the
'name' attribute and an incoming pool is using the parentaddr/unique_id,
then the code will attempt to compare the existing name string against
the incoming name string which doesn't exist (is NULL) and results in
a core (STREQ).

Conversely, if the existing pool used the parentaddr/unique_id and the
to be defined pool used the name, then the comparison would be against
the parentaddr, but since the incoming pool doesn't have one - that would
leave the comparison against a parentaddr of all 0's and a unique_id of 0,
which will always comparison to fail. This means someone could define the
same source adapter for two pools

In order to resolve this, adjust the code to get the 'host#' to be used
by the storage scsi backend in order to check/start the pool and make sure
the incoming definition doesn't match any of the existing pool defs.

The <sysinfo> data block was indented by 2 spaces too many.
This was missed because we never had any test validating
the XML formatting.

The mode attribute is required for the source element of vhost-user.
Thus virDomainNetDefFormat should always generate a xml with it and not
only when the mode is server.

The commit fixes the issue. And it adds a vhostuser interface in
'client' mode to qemuxml2argv-net-vhostuser.(args|xml) to test this
usecase.
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>

Shove it to the top of the file so that it can be reused earlier.

As in the device info iterator add a switch that will force the compiler
to check that new device types are added to the ABI stability checker.

Although the device will probably inhibit migration add checks to make
sure that the configuration change gets caught.

Use typecasted switch statement and note the type used to select the
address type in a comment.

Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Allow the Xen drivers to determine default vram values.  Sane
default vaules depend on the device model being used, so the
drivers are in the best position to determine the defaults.

For the legacy xen driver, it is best to maintain the existing
logic for setting default vram values to ensure there are no
regressions.  The libxl driver currently does not support
configuring a video device.  Support will be added in a
subsequent patch, where the benefit of this change will be
reaped.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This new attribute will control whether or not libvirt will pay
attention to guest notifications about changes to network device mac
addresses and receive filters. The default for this is 'no' (for
security reasons). If it is set to 'yes' *and* the specified device
model and connection support it (currently only macvtap+virtio) then
libvirt will watch for NIC_RX_FILTER_CHANGED events, and when it
receives one, it will issue a query-rx-filter command, retrieve the
result, and modify the host-side macvtap interface's mac address and
unicast/multicast filters accordingly.

The functionality behind this attribute will be in a later patch. This
patch merely adds the attribute to the top-level of a domain's
<interface> as well as to <network> and <portgroup>, and adds
documentation and schema/xml2xml tests. Rather than adding even more
test files, I've just added the net attribute in various applicable
places of existing test files.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This patch implements support for the ivshmem device in QEMU.
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This patch adds parsing/formatting code as well as documentation for
shared memory devices.  This will currently be only accessible in QEMU
using it's ivshmem device, but is designed as generic as possible to
allow future expansion for other hypervisors.

In the devices section in the domain XML users may specify:

- For shmem device using a server:

 <shmem name='shmem0'>
   <server path='/tmp/socket-ivshmem0'/>
   <size unit='M'>32</size>
   <msi vectors='32' ioeventfd='on'/>
 </shmem>

- For ivshmem device not using an ivshmem server:

 <shmem name='shmem1'>
   <size unit='M'>32</size>
 </shmem>

Most of the configuration is made optional so it also allows
specifications like:

 <shmem name='shmem1/>
 <shmem name='shmem2'>
   <server/>
 </shmem>
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

and tweak the code to avoid using it.

If you use public api virConnectListAllDomains() with second parameter
set to NULL to get only the number of domains you will lock out all
other operations with domains.

Introduced by commit 2c680804.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When detected invalid 'memAccess', virCPUDefParseXML should report error.

Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1146334Signed-off-by: NJincheng Miao <jmiao@redhat.com>

When virConnectDomainQemuMonitorEventRegister is called with the
VIR_CONNECT_DOMAIN_QEMU_MONITOR_EVENT_REGISTER_REGEX flag,
ignore the flag instead of crashing.

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

Add options for tuning segment offloading:
<driver>
  <host csum='off' gso='off' tso4='off' tso6='off'
        ecn='off' ufo='off'/>
  <guest csum='off' tso4='off' tso6='off' ecn='off' ufo='off'/>
</driver>
which control the respective host_ and guest_ properties
of the virtio-net device.

If you have a bridge network in running domain and libvirtd is restarted
the information about host bridge interface is lost from live xml.

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

This new event will use typedParameters to expose what has been actually
updated and the reason is that we can in the future extend any tunable
values or add new tunable values. With typedParameters we don't have to
worry about creating some other events, we will just use this universal
event to inform user about updates.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>