virDomainNumatuneParseXML now doesn't allocate the def->numa object any
longer so we don't need to pass a double pointer.

As virDomainNumatuneSet now doesn't allocate the virDomainNuma object
any longer it's not necessary to pass the pointer to a pointer to store
the object as it will not change any longer.

While touching the parameter definitions I've also changed the name of
the parameter to "numa".

Since our formatter now handles well if the config is allocated and not
filled we can safely always-allocate the NUMA config and remove the
ad-hoc allocation code.

This will help in later patches as the parser will be refactored to just
fill the data.

Use the virDomainDefNew() helper to allocate the definition instead of
doing it via VIR_ALLOC.

Move the existing virDomainDefNew to virDomainDefNewFull as it's setting
a few things in the conf and re-introduce virDomainDefNew as a function
without parameters for common use.

Do a content-aware check if formatting of the <numatune> element is
necessary. Later on the def->numa structure will be always present so we
cannot decide only on the basis whether it's allocated.

Shuffling around the logic will allow to simplify the code quite a bit.
As an additional bonus the change in the logic now reports an error if
automatic placement is selected and individual placement is configured.

Collapse few of the conditions so that the program flow is more clear.

Currently the code would exit without reporting an error as
virBitmapParse reports one only if it fails to parse the bitmap, whereas
the code was jumping to the error label even in case 0 cpus were
correctly parsed in the map.

It's easier to recalculate the number in the one place it's used as
having a separate variable to track it. It will also help with moving
the NUMA code to the separate module.

Name it virNumaMemAccess and add it to conf/numa_conf.[ch]

Note that to avoid a circular dependency the type of the NUMA cell
memAccess variable was changed to int. It will be turned back later
after the circular dependency will not exist.

The structure will gradually become the only place for NUMA related
config, thus rename it appropriately.

Move the code that formats the /domain/cpu/numa element to numa_conf as
it belongs there.

The mask was stored both as a bitmap and as a string. The string is used
for XML output only. Remove the string, as it can be reconstructed from
the bitmap.

The test change is necessary as the bitmap formatter doesn't "optimize"
using the '^' operator.

Rewrite the function to save a few local variables and reorder the code
to make more sense.

Additionally the ncells_max member of the virCPUDef structure is used
only for tracking allocation when parsing the numa definition, which can
be avoided by switching to VIR_ALLOC_N as the array is not resized
after initial allocation.

For weird historical reasons NUMA cells are added as a subelement of
<cpu> while the actual configuration is done in <numatune>.

This patch splits out the cell parser code from cpu config to NUMA
config. Note that the changes to the code are minimal just to make it
work and the function will be refactored in the next patch.

For a while now there are two places that gather information about NUMA
related guest configuration. While the XML can't be changed we can at
least store the data in one place in the definition.

Rename the numatune_conf.[ch] files to numa_conf as later patches will
move the rest of the definitions from the cpu definition to this one.

Not all files we want to find using virFileFindResource{,Full} are
generated when libvirt is built, some of them (such as RNG schemas) are
distributed with sources. The current API was not able to find source
files if libvirt was built in VPATH.

Both RNG schemas and cpu_map.xml are distributed in source tarball.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This function is going to be needed in the near future.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add an XML attribute to allow disabling merge of rx buffers
on the host:
<interface ...>
  ...
  <model type='virtio'/>
  <driver ...>
    <host mrg_rxbuf='off'/>
  </driver>
</interface>

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

In order for QEMU vCPU (and other) threads to run with RT scheduler,
libvirt needs to take care of that so QEMU doesn't have to run privileged.

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

Prior to commit 7d5bf484 (first appearing in libvirt 1.2.2), the
status XML of a domain's interface was missing a lot of important
information; mainly it just output the config of the interface, plus
the name of the tap device and qemu device alias. Commit 7d5bf484
changed the status XML to include many important bits of information
that were required to make network "hook" scripts useful - bandwidth
information, vlan tag, the name of the bridge (or physical device in
the case of macvtap) that the tap/macvtap device was attached to - the
commit log for 7d5bf484 has a very detailed explanation of the
change. For quick reference - in the example given there, prior to the
change, status XML looked like figure [C]:

      <interface type='network'>
        <source network='testnet' portgroup='admin'/>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

and after the change, it looked like figure [E]:

      <interface type='direct'>
        <source dev='p4p1_0' mode='bridge'/>
        <bandwidth>
            <inbound average='1000' peak='5000' burst='1024'/>
            <outbound average='128' peak='256' burst='256'/>
        </bandwidth>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

You'll notice that bandwidth info, physdev, and macvtap mode have been
added, but the network and portgroup names are now missing - I didn't
think that this information was of any use once the needed
bandwidth/vlan/etc config had been pulled from the network/portgroup.

I was wrong.

A few months after that change a user on IRC asked what happened to
portgroup in the status XML and described how he used it (more or less
as a tag to decide what external information to use in a hook script
that was run at startup/migration time - see
http://wiki.libvirt.org/page/OVS_and_PVLANS ). At that time I planned
to make a patch to re-add portgroup, but life intervened as that was
just prior to a transatlantic move involving several weeks of
"vacation". During this time I somehow forgot to make the patch, and
also mistakenly remembered that I *had* made it.

Subsequent to this, as a part of mprivozn's work to add support for
network-specific hooks, I did re-add the output of the network name in
status XML, but once again completely forgot about portgroup. This was
in commit a3609121 (first appearing in libvirt 1.2.11). This made the
status XML from the above example look like this:

      <interface type='direct'>
        <source network='testnet' dev='p4p1_0' mode='bridge'/>
        <bandwidth>
            <inbound average='1000' peak='5000' burst='1024'/>
            <outbound average='128' peak='256' burst='256'/>
        </bandwidth>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

*This* patch just adds the portgroup back to the status XML, so the
 same example interface will look like this:

      <interface type='direct'>
        <source network='testnet' portgroup='admin'
                dev='p4p1_0' mode='bridge'/>
        <bandwidth>
            <inbound average='1000' peak='5000' burst='1024'/>
            <outbound average='128' peak='256' burst='256'/>
        </bandwidth>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

The result is that the status XML now contains all information about
how the interface is setup (bandwidth, physical device, tap device,
etc), in addition to pointers to its origin (the network and
portgroup).

virDomainGraphicsListenSetAddress() and
virDomainGraphicsListenSetNetwork() both set their respective char* to
NULL directly when asked to set it to NULL, which is okay as long as
it's already set to NULL. If these functions are ever called to clear
a listen object that has a valid string in address or network, it will
end up leaking the old value. Currently that doesn't happen, so this
is just a preemptive strike.

Prior to 0.9.4, libvirt only supported a single listen, and it had to
be an IP address:

   <graphics listen='1.2.3.4' ..../>

Starting with 0.9.4, a graphics element could have a <listen>
subelement (actually the grammar supports multiples, but all of the
drivers only support a single <listen> per <graphics>), and that
listen element can be of type='address' or type='network'. For
type='address', <listen> also has an attribute called 'address' which
contains the IP address for listening:

    <graphics ....>
      <listen type='address' address='1.2.3.4' .../>
    </graphics>

type can also be "network", and in that case listen will have a
"network" attribute which will contain the name of a libvirt
network:

    <graphics ....>
      <listen type='network' network='testnet' .../>
    </graphics>

At domain start (or migrate) time, libvirt will attempt to
find an IP address associated with that network (e.g. the IP address
of the bridge device used by the network, or the physical device
listed in <forward dev='physdev'/>) and fill in that address in the
status XML:

    <graphics ....>
      <listen type='network' network='testnet' address='1.2.3.4' .../>
    </graphics>

In the case that a <graphics> element has a <listen> subelement of
type='address', that listen subelement's "address" attribute is
backfilled into the parent graphics element's "listen" *attribute* for
backward compatibility (so that a management application unaware of
the separate <listen> element can still learn the listen
address). This backfill should be done with the IP learned from
type='network' as well, and that's what this patch does:

    <graphics listen='1.2.3.4' ....>
      <listen type='network' network='testnet' address='1.2.3.4' .../>
    </graphics>

This is a continuation of the fix for:

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

The function virDomainVcpuPinDel() used vcpupin_list to stand for
def->cputune.vcpupin, which made the codes more readable.
However, in this function, it will realloc vcpupin_list later.
As the definition of realloc(), it may free vcpupin_list and then
points it to a new-realloced address, but def->cputune.vcpupin doesn't
point to the new address(it's freed however).
Thus,
1) When we refer to the def->cputune.vcpupin afterwards, which was freed
by realloc(), an INVALID READ occurs, and libvirtd may crash.
2) As no one will use vcpupin_list any more, and no one frees it(it's just
alloced by realloc()), memory leak occurs.

Part of the valgrind logs are shown as below:
==1837== Thread 15:
==1837== Invalid read of size 8
==1837==    at 0x5367337: virDomainDefFormatInternal (domain_conf.c:18392)
        which is : virBufferAsprintf(buf, "<vcpupin vcpu='%u' ",
                          def->cputune.vcpupin[i]->vcpuid);
==1837==    by 0x536966C: virDomainObjFormat (domain_conf.c:18970)
==1837==    by 0x5369743: virDomainSaveStatus (domain_conf.c:19166)
==1837==    by 0x117B26DC: qemuDomainPinVcpuFlags (qemu_driver.c:4586)
==1837==    by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803)
==1837==    by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762)
==1837==    by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740)
==1837==    by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==1837==    by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307)
==1837==    by 0x171B83: virNetServerProcessMsg (virnetserver.c:172)
==1837==    by 0x171E6E: virNetServerHandleJob (virnetserver.c:193)
==1837==    by 0x5318E78: virThreadPoolWorker (virthreadpool.c:145)
==1837==  Address 0x12ea2870 is 0 bytes inside a block of size 16 free'd
==1837==    at 0x4C291AC: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1837==    by 0x52A3D14: virReallocN (viralloc.c:245)
==1837==    by 0x52A3DFB: virShrinkN (viralloc.c:372)
==1837==    by 0x52A3F57: virDeleteElementsN (viralloc.c:503)
==1837==    by 0x533939E: virDomainVcpuPinDel (domain_conf.c:15405)  //doReset为true时才会进到。
==1837==    by 0x117B2642: qemuDomainPinVcpuFlags (qemu_driver.c:4573)
==1837==    by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803)
==1837==    by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762)
==1837==    by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740)
==1837==    by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==1837==    by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307)
==1837==    by 0x171B83: virNetServerProcessMsg (virnetserver.c:172)

Steps to reproduce the problem:
1) use virDomainPinVcpuFlags() to pin a guest's vcpu to all the pcpus
of the host.

This patch uses def->cputune.vcpupin instead of vcpupin_list to do the
realloc() job, to avoid invalid read or memory leaking.
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
Signed-off-by: Yue Wenyuan <yuewenyuan@huawei.com@huawei.com>

Parser checks for per-domain seclabel duplicates, so it would be nice if
it checked for per-device seclabel duplicates the same way

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

The helpers will be useful when implementing hotplug and coldplug of
random number generator devices.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NLuyao Huang <lhuang@redhat.com>

When adding devices to the definition it's useful to check whether the
devices don't reside on a conflicting address. This patch adds a helper
that iterates all device info and compares the addresses with the given
info.

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

It is only supported for virtio adapters.
Silently drop it if it was specified for other models,
as is done for other virtio attributes.

Also mention this in the documentation.

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

Commit id '652a2ec6' introduced two new node device capability flags
and the ability to use those flags as a way to search for a specific
subset of a 'scsi_host' device - namely a 'fc_host' and/or 'vports'.
The code modified the virNodeDeviceCapMatch whichs allows for searching
using the 'virsh nodedev-list [cap]' via virConnectListAllNodeDevices.

However, the original patches did not account for other searches for
the same capability key from virNodeListDevices using virNodeDeviceHasCap.
Since 'fc_host' and 'vports' are self defined bits of a 'scsi_host'
device mere string comparison against the basic/root type is not
sufficient.

This patch adds the check for the 'fc_host' and 'vports' bits within
a 'scsi_host' device and allows the following python code to find the
capabilities for the device:

import libvirt
conn = libvirt.openReadOnly('qemu:///system')
fc = conn.listDevices('fc_host', 0)
print(fc)
fc = conn.listDevices('vports', 0)
print(fc)
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

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

Add a missing jump to the error label in case the input device bus is
invalid.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Add the missing jump to thje error label. The error message shouldn't
ever be triggered though as it's called only on pre-selected nodes.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Extract the logic to determine which nodeset has to be used for a domain
from the formatting step so that it can be reused separately when the
nodeset is used in a different way.

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

In one of our previous commits (dc8b7ce7) we've done a functional
change even though it was intended as pure refactor. The problem is,
that the following XML:

 <vcpu placement='static' current='2'>6</vcpu>
 <cputune>
   <emulatorpin cpuset='1-3'/>
 </cputune>
 <numatune>
   <memory mode='strict' placement='auto'/>
 </numatune>

gets translated into this one:

 <vcpu placement='auto' current='2'>6</vcpu>
 <cputune>
   <emulatorpin cpuset='1-3'/>
 </cputune>
 <numatune>
   <memory mode='strict' placement='auto'/>
 </numatune>

We should not change the vcpu placement mode. Moreover, we're doing
something similar in case of emulatorpin and iothreadpin. If they were
set, but vcpu placement was auto, we've mistakenly removed them from
the domain XML even though we are able to set them independently on
vcpus.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After virBitmapEqual is able to compare NULL bitmaps few bits of code
can be cleaned up.

Do the allocation first, then add the actual device.
The second part should never fail. This is good
for live hotplug where we don't want to remove the device
on OOM after the monitor command succeeded.

The only change in behavior is that on failure, the
vmdef->consoles array is freed, not just the first console.

Currently when launching the LXC controller we first write out
the plain, inactive XML configuration, then launch the controller,
then replace the file with the live status XML configuration.
By good fortune this hasn't caused any problems other than some
misleading error messages during failure scenarios.

This simplifies the code so it only writes out the XML once and
always writes the live status XML. To do this we need to handshake
with the child process, to make execution pause just before exec()
so we can write the XML status with the child PID present.