If qemuMonitorBlockJob returned 0, qemuDomainBlockPivot
might return 0 even if an error occured.

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

By providing the implementation of nodeGetCellsFreeMemory for
the driver. This is all just a matter of properly formatting, in
a way that libvirt like, what Xen provides via libxl_get_numainfo().

[raistlin@Zhaman ~]$ sudo virsh --connect xen:/// freecell --all
    0:      25004 KiB
    1:     105848 KiB
--------------------
Total:     130852 KiB
Signed-off-by: NDario Faggioli <dario.faggioli@citrix.com>

On mingw, configure sets the name of the lxc symfile to
libvirt_lxc.defs rather than libvirt_lxc.syms.  But tarballs
must be arch-independent, regardless of the configure options
used for the tree where we ran 'make dist'.  This led to the
following failure in autobuild.sh:

  CCLD     libvirt-lxc.la
  CCLD     libvirt-qemu.la
/usr/lib64/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld: cannot find libvirt_lxc.def: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [libvirt-lxc.la] Error 1
make[3]: *** Waiting for unfinished jobs....

We were already doing the right thing with libvirt_qemu.syms.

* src/Makefile.am (EXTRA_DIST): Don't ship a built file which
depends on configure for its final name.
Signed-off-by: NEric Blake <eblake@redhat.com>

Found while trying to cross-compile to mingw:

  CC       libvirt_driver_remote_la-remote_driver.lo
../../src/remote/remote_driver.c: In function 'doRemoteOpen':
../../src/remote/remote_driver.c:487:23: error: variable 'verify' set but not used [-Werror=unused-but-set-variable]

* src/remote/remote_driver.c (doRemoteOpen): Also ignore 'verify'.
Signed-off-by: NEric Blake <eblake@redhat.com>

iptablesContext holds only 4 pairs of iptables
(table, chain) and there's no need to pass
it around.

This is a first step towards separating bridge_driver.c
in platform-specific parts.

Implement check whether (maximum) vCPUs doesn't exceed machine
type's cpu-max settings.

On older versions of QEMU the check is disabled.
Signed-off-by: NMichal Novotny <minovotn@redhat.com>

On Thu, Jun 27, 2013 at 03:56:42PM +0100, Daniel P. Berrange wrote:
> Hi Security Team,
>
> I've discovered a way for an unprivileged user with a readonly connection
> to libvirtd, to crash the daemon.

Ok, the final patch for this is issue will be the simpler variant that
Eric suggested

The embargo can be considered to be lifted on Monday July 1st, at
0900 UTC

The following is the GIT change that DV or myself will apply to libvirt
GIT master immediately before the 1.1.0 release:

>From 177b4165c531a4b3ba7f6ab6aa41dca9ceb0b8cf Mon Sep 17 00:00:00 2001
From: "Daniel P. Berrange" <berrange@redhat.com>
Date: Fri, 28 Jun 2013 10:48:37 +0100
Subject: [PATCH] CVE-2013-2218: Fix crash listing network interfaces with
 filters

The virConnectListAllInterfaces method has a double-free of the
'struct netcf_if' object when any of the filtering flags cause
an interface to be skipped over. For example when running the
command 'virsh iface-list --inactive'

This is a regression introduced in release 1.0.6 by

  commit 7ac2c4fe
  Author: Guannan Ren <gren@redhat.com>
  Date:   Tue May 21 21:29:38 2013 +0800

    interface: list all interfaces with flags == 0
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=971325

The problem was that if virPCIGetVirtualFunctions was given the name
of a non-existent interface, it would return to its caller without
initializing the pointer to the array of virtual functions to NULL,
and the caller (virNetDevGetVirtualFunctions) would try to VIR_FREE()
the invalid pointer.

The final error message before the crash would be:

 virPCIGetVirtualFunctions:2088 :
  Failed to open dir '/sys/class/net/eth2/device':
  No such file or directory

In this patch I move the initialization in virPCIGetVirtualFunctions()
to the begining of the function, and also do an explicit
initialization in virNetDevGetVirtualFunctions, just in case someone
in the future adds code into that function prior to the call to
virPCIGetVirtualFunctions.

This fixes:

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

The node device driver was written with the assumption that udev would
use a "change" event to notify libvirt of any change to device status
(including the name of the driver it was bound to). It turns out this
is not the case (see Comment 4 of BZ 979290). That means that a
dumpxml for a device would always show whatever driver happened to be
bound at the time libvirt was started (when the node device cache was
built).

There was already code in the driver (for the benefit of the HAL
backend) that updated the driver name from sysfs each time a device's
info was retrieved from the cache. This patch just enables that manual
update for the udev backend as well.

There were two errors, one as a direct result of commit id '8807b285'
and the other from cut-n-paste

TEST: nodedevxml2xmltest
      ..............                           14  OK
==25735== 3 bytes in 1 blocks are definitely lost in loss record 1 of 24
==25735==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==25735==    by 0x344D2AF275: xmlStrndup (in /usr/lib64/libxml2.so.2.9.1)
==25735==    by 0x4D0C767: virNodeDeviceDefParseNode (node_device_conf.c:997)
==25735==    by 0x4D0D3D2: virNodeDeviceDefParse (node_device_conf.c:1337)
==25735==    by 0x401CA4: testCompareXMLToXMLHelper (nodedevxml2xmltest.c:28)
==25735==    by 0x402B2F: virtTestRun (testutils.c:158)
==25735==    by 0x401B27: mymain (nodedevxml2xmltest.c:81)
==25735==    by 0x40316A: virtTestMain (testutils.c:722)
==25735==    by 0x37C1021A04: (below main) (libc-start.c:225)
==25735==
==25735== 16 bytes in 1 blocks are definitely lost in loss record 10 of 24
==25735==    at 0x4A08A6E: realloc (vg_replace_malloc.c:662)
==25735==    by 0x4C7385E: virReallocN (viralloc.c:184)
==25735==    by 0x4C73906: virExpandN (viralloc.c:214)
==25735==    by 0x4C73B4A: virInsertElementsN (viralloc.c:324)
==25735==    by 0x4D0C84C: virNodeDeviceDefParseNode (node_device_conf.c:1026)
==25735==    by 0x4D0D3D2: virNodeDeviceDefParse (node_device_conf.c:1337)
==25735==    by 0x401CA4: testCompareXMLToXMLHelper (nodedevxml2xmltest.c:28)
==25735==    by 0x402B2F: virtTestRun (testutils.c:158)
==25735==    by 0x401B27: mymain (nodedevxml2xmltest.c:81)
==25735==    by 0x40316A: virtTestMain (testutils.c:722)
==25735==    by 0x37C1021A04: (below main) (libc-start.c:225)
==25735==
PASS: nodedevxml2xmltest

The first error was resolved by adding a missing VIR_FREE(numberStr); in
the new function virNodeDevCapPciDevIommuGroupParseXML().

The second error was a bit more opaque as the error was a result of copying
the free methodolgy of the existing code in virNodeDevCapsDefFree(). The code
would free each of the entries in the array, but not the memory for the
array itself.  Added the necessary VIR_FREE(data->pci_dev.iommuGroupDevices)
and while at it added the missing VIR_FREE(data->pci_dev.virtual_functions)
although there wasn't a test that tripped across it (thus it's been lurking
since commit id 'a010165d').

Commit id '53d5967c' introduced the following:

TEST: storagevolxml2argvtest
      ..............                           14  OK
==25636== 358 (264 direct, 94 indirect) bytes in 1 blocks are definitely lost in loss record 67 of 75
==25636==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==25636==    by 0x4C95791: virAlloc (viralloc.c:124)
==25636==    by 0x4CA0BB4: virCommandNewArgs (vircommand.c:805)
==25636==    by 0x4CA0C88: virCommandNew (vircommand.c:789)
==25636==    by 0x408602: virStorageBackendCreateQemuImgCmd (storage_backend.c:849)
==25636==    by 0x405427: testCompareXMLToArgvHelper (storagevolxml2argvtest.c:61)
==25636==    by 0x4064DF: virtTestRun (testutils.c:158)
==25636==    by 0x40516F: mymain (storagevolxml2argvtest.c:195)
==25636==    by 0x406B1A: virtTestMain (testutils.c:722)
==25636==    by 0x37C1021A04: (below main) (libc-start.c:225)
==25636==
PASS: storagevolxml2argvtest

Commit '861d4056' introduced the following:

TEST: networkxml2xmltest
      ..................                       18  OK
==25504== 7 bytes in 1 blocks are definitely lost in loss record 5 of 23
==25504==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==25504==    by 0x37C1085D71: strdup (strdup.c:42)
==25504==    by 0x4CB835F: virStrdup (virstring.c:546)
==25504==    by 0x4CC5179: virXPathString (virxml.c:90)
==25504==    by 0x4CC75C2: virNetDevVlanParse (netdev_vlan_conf.c:78)
==25504==    by 0x4CF928A: virNetworkPortGroupParseXML (network_conf.c:1555)
==25504==    by 0x4CFE385: virNetworkDefParseXML (network_conf.c:2049)
==25504==    by 0x4D0113B: virNetworkDefParseNode (network_conf.c:2273)
==25504==    by 0x4D01254: virNetworkDefParse (network_conf.c:2234)
==25504==    by 0x401E80: testCompareXMLToXMLHelper (networkxml2xmltest.c:32)
==25504==    by 0x402D4F: virtTestRun (testutils.c:158)
==25504==    by 0x401CE9: mymain (networkxml2xmltest.c:110)
==25504==
PASS: networkxml2xmltest

Also changed the label from error to cleanup and adjusted code since it's
all one exit path

The IF_MAXUNIT macro is not present on all BSDs, so
make its use conditional, to avoid breaking OS-X.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The 'in_addr_t' typedef is not present in Mingw64 headers.
Instead we can use the more portable 'struct in_addr' and
then access its 's_addr' field.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The udev based interface backend did not allow querying data over a
read-only connection which is different than how the netcf backend
operates. This brings the behavior inline with the default, netcf
backend.

VPATH build failed for the generated access driver files.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

When creating a virtual FC HBA with virsh/libvirt API, an error message
will be returned: "error: Node device not found",
also the 'nodedev-dumpxml' shows wrong information of wwpn & wwnn
for the new created device.

Signed-off-by: xschen@tnsoft.com.cn

This reverts f90af691 which switched wwpn & wwwn in the wrong place.

https://www.kernel.org/doc/Documentation/scsi/scsi_fc_transport.txt

Building on FreeBSD had this linker error:

/work/a/ports/devel/libvirt/work/libvirt-1.1.0/src/.libs/libvirt.so:
   undefined reference to `virPCIDeviceAddressParse'

This was caused by the new use of virPCIDeviceAddressParse in a
portion of virpci.c that wasn't linux-only (in commit 72c029d8). The
problem was that virPCIDeviceAddressParse had originally been defined
inside #ifdef _linux (because it was only used by another function
that was inside the same ifdef).

The solution is to move it out to the part of virpci.c that is
compiled on all platforms.

(Because the portion that was "moved" was 40-50 lines, but only moved
up by 15 lines, the diff for the patch is less than non-informative -
rather than showing that part that I moved, it shows the bit that was
previously before the moved part, and now sits *after* it.)

Implicit controllers may be dependent on device definitions altered
in a post-parse callback. Specifically, if a console device is
defined without the target type, the type will be set in QEMU's
callback. In the case of s390, this is virtio, which requires
an implicit virtio-serial controller.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

If networkUnplugBandwidth is called on a network which has
no bandwidth defined, print a warning instead of crashing.

This can happen when destroying a domain with bandwidth if
bandwidth was removed from the network after the domain was
started.

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

This includes adding it to the nodedev parser and formatter, docs, and
test.

An example of the new iommuGroup element that is a part of the output
from "virsh nodedev-dumpxml" (virNodeDeviceGetXMLDesc()):

  <device>
    <name>pci_0000_02_00_1</name>
    <capability type='pci'>
    ...
      <iommuGroup number='12'>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
      </iommuGroup>
    </capability>
  </device>

Any device which belongs to an "IOMMU group" (used by vfio) will
have links to all devices of its group listed in
/sys/bus/pci/$device/iommu_group/devices;
/sys/bus/pci/$device/iommu_group is actually a link to
/sys/kernel/iommu_groups/$n, where $n is the group number (there
will be a corresponding device node at /dev/vfio/$n once the
devices are bound to the vfio-pci driver)

The following functions are added:

virPCIDeviceGetIOMMUGroupList

  Gets a virPCIDeviceList with one virPCIDeviceList for each device
  in the same IOMMU group as the provided virPCIDevice (a copy of the
  original device object is included in the list.

virPCIDeviceAddressIOMMUGroupIterate

  Calls the function @actor once for each device in the group that
  contains the given virPCIDeviceAddress.

virPCIDeviceAddressGetIOMMUGroupAddresses

  Fills in a virPCIDeviceAddressPtr * with an array of
  virPCIDeviceAddress, one for each device in the iommu group of the
  provided virPCIDeviceAddress (including a copy of the original).

virPCIDeviceAddressGetIOMMUGroupNum

  Returns the group number as an int (a valid group number will always
  be 0 or greater).  If there is no iommu_group link in the device's
  directory (usually indicating that vfio isn't loaded), -2 will be
  returned. On any real error, -1 will be returned.

We only break out of the while loop if *content is an empty string.
However the buffer has been allocated to BUFSIZ + 1 (8193 in my case),
but it gets overwritten in the next for iteration.

Move VIR_FREE right before we overwrite it to avoid the leak.

==5777== 16,386 bytes in 2 blocks are definitely lost in loss record 1,022 of 1,027
==5777==    by 0x5296E28: virReallocN (viralloc.c:184)
==5777==    by 0x52B0C66: virFileReadLimFD (virfile.c:1137)
==5777==    by 0x52B0E1A: virFileReadAll (virfile.c:1199)
==5777==    by 0x529B092: virCgroupGetValueStr (vircgroup.c:534)
==5777==    by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079)

Introduced by 83e4c775.

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

Don't check for '\n' at the end of file if zero bytes were read.

Found by valgrind:
==404== Invalid read of size 1
==404==    at 0x529B09F: virCgroupGetValueStr (vircgroup.c:540)
==404==    by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079)
==404==    by 0x1EB475: qemuSetupCgroupForEmulator (qemu_cgroup.c:1061)
==404==    by 0x1D9489: qemuProcessStart (qemu_process.c:3801)
==404==    by 0x18557E: qemuDomainObjStart (qemu_driver.c:5787)
==404==    by 0x190FA4: qemuDomainCreateWithFlags (qemu_driver.c:5839)

Introduced by 0d0b4098.

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

Although SRIOV network cards support setting a vlan tag on their
virtual functions, and although setting this vlan tag via a <vlan>
element in a domain's <interface> works, setting a vlan tag for these
devices in a <network> definition, or in a network <portgroup>
definition is also supposed to work (and the comment that validates
<vlan> usage even says that!). However, the check to allow it only
checked for an openvswitch network, so attempts to add <vlan> to a
network of type='hostdev' would fail.

A loop in qemuPrepareHostdevPCIDevices() intended to cycle through all
the objects on the list pcidevs was doing "while (listcount > 0)", but
nothing in the body of the loop was reducing the size of the list - it
was instead removing items from a *different* list. It has now been
safely changed to a for() loop.

(This isn't as bad as it sounds - it's only a problem in case of an
OOM error.)

qemuGetActivePciHostDeviceList() had been creating a list that
contained pointers to objects that were also on the activePciHostdevs
list. In case of an OOM error, this newly created list would be
virObjectUnref'ed, which would cause everything on the list to be
freed. But all of those objects would still be on the
activePciHostdevs list, which could have very bad consequences if that
list was ever again accessed.

The solution used here is to populate the new list with *copies* of
the objects from the original list. It turns out that on return from
qemuGetActivePciHostDeviceList(), the caller would almost immediately
go through all the device objects and "steal" them (i.e. remove the
pointer from the list but not delete it) all from either one list or
the other; we now instead just *delete* (remove from the list and
free) each device from one list or the other, so in the end we have
the same state.

The "fix" I pushed a few commits ago would still leak a virPCIDevice
in case of an OOM error. Although it's inconsequential in practice,
this patch satisfies my OCD.

Make a copy of the device and add the copy to the
list. (virPCIDeviceListAdd() adds the original object to the list
instead).

If the device is bound to a stub driver different from what is saved
in the virPCIDevice's stubDriver attribute, update it.

The same strings were being re-created multiple times just to save
declaring a new variable. In the meantime, the use of the generic
variable names led to confusion when trying to follow the code. This
patch creates strings for:

 stubDriverName  (was called "driver" in original args)
 stubDriverPath  ("/sys/bus/pci/drivers/${stubDriverName}")
 driverLink      ("${device}/driver")
 oldDriverName   (the final component of path linked to by
                  "${device}/driver")
 oldDriverPath   ("/sys/bus/pci/drivers/${oldDriverName}")

then re-uses them as necessary.

This function has utility outside of virpci.c, so make it public.

Also the name didn't fit convention, so change it to
virPCIDeviceAddressParse.

I realized after the fact that it's probably better in the long run to
give this function a name that matches the name of the link used in
sysfs to hold the group (iommu_group).

I'm changing it now because I'm about to add several more functions
that deal with iommu groups.

The driver arg to virPCIDeviceDetach is no longer used (the name of the stub driver is now set in the virPCIDevice object, and virPCIDeviceDetach retrieves it from there). Remove it.

Commit 861d4056 added code (my personal change to "clean up" the
submitter's code, *not* the fault of the submitter) that dereferenced
virtVlan without first checking for NULL. This patch fixes that and,
as part of the fix, cleans up some unnecessary obtuseness.