1. 26 6月, 2013 2 次提交
  2. 25 6月, 2013 5 次提交
    • L
      pci: make virPCIDeviceDetach consistent in behavior · 9b4a6666
      Laine Stump 提交于
      virPCIDeviceDetach would previously sometimes consume the input device
      object (to put it on the inactive list) and sometimes not. Avoiding
      memory leaks required checking beforehand to see if the device was
      already on the list, and freeing the device object in the caller only
      if there wasn't already an identical object on the inactive list.
      
      This patch makes it consistent - virPCIDeviceDetach will *never*
      consume the input virPCIDevice object; if it needs to put one on the
      inactive list, it will create a copy and put *that* on the list. This
      way the caller knows that it is always their responsibility to free
      the device object they created.
      9b4a6666
    • L
      pci: eliminate memory leak in virPCIDeviceReattach · f962e8b6
      Laine Stump 提交于
      virPCIDeviceReattach was making the assumption that the dev object
      given to it was one and the same with the dev object on the
      inactiveDevs list. If that had been the case, it would not need to
      free the dev object it removed from the inactive list, because the
      caller of virPCIDeviceReattach always frees the dev object that it
      passes in. Since the dev object passed in is *never* the same object
      that's on the list (it is a different object with the same name and
      attributes, created just for the purpose of searching for the actual
      object), simply doing a "ListSteal" to remove the object from the list
      results in one leaked object; we need to actually free the object
      after removing it from the list.
      f962e8b6
    • L
      pci: new utility functions · 50a8d850
      Laine Stump 提交于
      * virPCIDeviceFindByIDs - find a device on a list w/o creating an object
          This makes searching for an existing device on a list lighter weight.
      
      * virPCIDeviceCopy - make a copy of an existing virPCIDevice object.
      
      * virPCIDeviceGetDriverPathAndName - construct new strings containing
          1) the name of the driver bound to this device.
          2) the full path to the sysfs config for that driver.
          (This code was lifted from virPCIDeviceUnbindFromStub, and replaced
          there with a call to this new function).
      50a8d850
    • L
      pci: change stubDriver from const char* to char* · 53e52b4a
      Laine Stump 提交于
      Previously stubDriver was always set from a string literal, so it was
      okay to use a const char * that wasn't freed when the virPCIDevice was
      freed. This will not be the case in the near future, so it is now a
      char* that is allocated in virPCIDeviceSetStubDriver() and freed
      during virPCIDeviceFree().
      53e52b4a
    • L
      syntax: virPCIDeviceFree is also a NOP for NULL args · d80d0d5d
      Laine Stump 提交于
      add it to the syntax-check list and fix the one offending caller.
      d80d0d5d
  3. 06 6月, 2013 1 次提交
  4. 24 5月, 2013 1 次提交
  5. 02 5月, 2013 2 次提交
    • M
      virutil: Move string related functions to virstring.c · 7c9a2d88
      Michal Privoznik 提交于
      The source code base needs to be adapted as well. Some files
      include virutil.h just for the string related functions (here,
      the include is substituted to match the new file), some include
      virutil.h without any need (here, the include is removed), and
      some require both.
      7c9a2d88
    • L
      pci: autolearn name of stub driver, remove from arglist · e482693b
      Laine Stump 提交于
      virPCIDeviceReattach and virPCIDeviceUnbindFromStub (called by
      virPCIDeviceReattach) had previously required the name of the stub
      driver as input. This is unnecessary, because the name of the driver
      the device is currently bound to can be found by looking at the link:
      
        /sys/bus/pci/dddd:bb:ss.ff/driver
      
      Instead of requiring that the name of the expected stub driver name
      and only unbinding if that one name is matched, we no longer take a
      driver name in the arglist for either of these
      functions. virPCIDeviceUnbindFromStub just compares the name of the
      currently bound driver to a list of "well known" stubs (right now
      contains "pci-stub" and "vfio-pci" for qemu, and "pciback" for xen),
      and only performs the unbind if it's one of those devices.
      
      This allows virsh nodedevice-reattach to work properly across a
      libvirtd restart, and fixes a couple of cases where we were
      erroneously still hard-coding "pci-stub" as the drive name.
      
      For some unknown reason, virPCIDeviceReattach had been calling
      modprobe on the stub driver prior to unbinding the device. This was
      problematic because we no longer know the name of the stub driver in
      that function. However, it is pointless to probe for the stub driver
      at that time anyway - because the device is bound to the stub driver,
      we are guaranteed that it is already loaded, and so that call to
      modprobe has been removed.
      e482693b
  6. 26 4月, 2013 3 次提交
    • L
      util: new function virPCIDeviceGetVFIOGroupDev · b210208f
      Laine Stump 提交于
      Given a virPCIDevice, this function returns the path for the device
      that controls the vfio group the device belongs to,
      e.g. "/dev/vfio/15".
      b210208f
    • L
      pci: keep a stubDriver in each virPCIDevice · be64199e
      Laine Stump 提交于
      This can be set when the virPCIDevice is created and placed on a list,
      then used later when traversing the list to determine which stub
      driver to bind/unbind for managed devices.
      
      The existing Detach and Attach functions' signatures haven't been
      changed (they still accept a stub driver name in the arg list), but if
      the arg list has NULL for stub driver and one is available in the
      device's object, that will be used. (we may later deprecate and remove
      the arg from those functions).
      be64199e
    • E
      build: avoid unsafe functions in libgen.h · 1fbf1905
      Eric Blake 提交于
      POSIX says that both basename() and dirname() may return static
      storage (aka they need not be thread-safe); and that they may but
      not must modify their input argument.  Furthermore, <libgen.h>
      is not available on all platforms.  For these reasons, you should
      never use these functions in a multi-threaded library.
      
      Gnulib instead recommends a way to avoid the portability nightmare:
      gnulib's "dirname.h" provides useful thread-safe counterparts.  The
      obvious dir_name() and base_name() are GPL (because they malloc(),
      but call exit() on failure) so we can't use them; but the LGPL
      variants mdir_name() (malloc's or returns NULL) and last_component
      (always points into the incoming string without modifying it,
      differing from basename semantics only on corner cases like the
      empty string that we shouldn't be hitting in the first place) are
      already in use in libvirt.  This finishes the swap over to the safe
      functions.
      
      * cfg.mk (sc_prohibit_libgen): New rule.
      * src/util/vircgroup.c: Fix offenders.
      * src/parallels/parallels_storage.c (parallelsPoolAddByDomain):
      Likewise.
      * src/parallels/parallels_network.c (parallelsGetBridgedNetInfo):
      Likewise.
      * src/node_device/node_device_udev.c (udevProcessSCSIHost)
      (udevProcessSCSIDevice): Likewise.
      * src/storage/storage_backend_disk.c
      (virStorageBackendDiskDeleteVol): Likewise.
      * src/util/virpci.c (virPCIGetDeviceAddressFromSysfsLink):
      Likewise.
      * src/util/virstoragefile.h (_virStorageFileMetadata): Avoid false
      positive.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1fbf1905
  7. 20 4月, 2013 1 次提交
    • E
      docs: fix usage of 'onto' · 1bf25ba2
      Eric Blake 提交于
      http://www.uhv.edu/ac/newsletters/writing/grammartip2009.07.01.htm
      (and several other sites) give hints that 'onto' is best used if
      you can also add 'up' just before it and still make sense. In many
      cases in the code base, we really want the two-word form, or even
      a simplification to just 'on' or 'to'.
      
      * docs/hacking.html.in: Use correct 'on to'.
      * python/libvirt-override.c: Likewise.
      * src/lxc/lxc_controller.c: Likewise.
      * src/util/virpci.c: Likewise.
      * daemon/THREADS.txt: Use simpler 'on'.
      * docs/formatdomain.html.in: Better usage.
      * docs/internals/rpc.html.in: Likewise.
      * src/conf/domain_event.c: Likewise.
      * src/rpc/virnetclient.c: Likewise.
      * tests/qemumonitortestutils.c: Likewise.
      * HACKING: Regenerate.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1bf25ba2
  8. 15 4月, 2013 1 次提交
    • O
      Use unsigned int instead of unsigned · b1ea781e
      Osier Yang 提交于
      Though they are the same thing, mixed use of them is uncomfortable.
      "unsigned" is used a lot in old codes, this just tries to change the
      ones in utils.
      b1ea781e
  9. 11 4月, 2013 2 次提交
  10. 10 4月, 2013 1 次提交
    • L
      Fix crash in virNetDevGetVirtualFunctions · 9579b6bc
      Laine Stump 提交于
      Commit 9a3ff01d (which was ACKed at
      the end of January, but for some reason didn't get pushed until during
      the 1.0.4 freeze) fixed the logic in virPCIGetVirtualFunctions().
      Unfortunately, a typo in the fix (replacing VIR_REALLOC_N with
      VIR_ALLOC_N during code movement) caused not only a memory leak, but
      also resulted in most of the elements of the result array being
      replaced with NULL. virNetDevGetVirtualFunctions() assumed (and I think
      rightly so) that virPCIGetVirtualFunctions() wouldn't return any NULL
      elements in the array, so it ended up segfaulting.
      
      This was found when attempting to use a virtual network with an
      auto-created pool of SRIOV VFs, e.g.:
      
          <forward mode='hostdev' managed='yes'>
            <pf dev='eth4'/>
          </forward>
      
      (the pool of PCI addresses is discovered by calling
      virNetDevGetVirtualFunctions() on the PF dev).
      9579b6bc
  11. 25 3月, 2013 1 次提交
    • O
      nodedev: Fix the improper logic when enumerating SRIOV VF · 9a3ff01d
      Osier Yang 提交于
      virPCIGetVirtualFunctions returns 0 even if there is no "virtfn"
      entry under the device sysfs path.
      
      And virPCIGetVirtualFunctions returns -1 when it fails to get
      the PCI config space of one VF, however, with keeping the
      the VFs already detected.
      
      That's why udevProcessPCI and gather_pci_cap use logic like:
      
      if (!virPCIGetVirtualFunctions(syspath,
                                     &data->pci_dev.virtual_functions,
                                     &data->pci_dev.num_virtual_functions) ||
          data->pci_dev.num_virtual_functions > 0)
          data->pci_dev.flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VIRTUAL_FUNCTION;
      
      to tag the PCI device with "virtual_function" cap.
      
      However, this results in a VF will aslo get "virtual_function" cap.
      
      This patch fixes it by:
        * Ignoring the VF which has failure of getting PCI config space
          (given that the successfully detected VFs are kept , it makes
          sense to not give up on the failure of one VF too) with a warning,
          so virPCIGetVirtualFunctions will not return -1 except out of memory.
      
        * Free the allocated *virtual_functions when out of memory
      
      And thus the logic can be changed to:
      
          /* Out of memory */
          int ret = virPCIGetVirtualFunctions(syspath,
                                              &data->pci_dev.virtual_functions,
                                              &data->pci_dev.num_virtual_functions);
      
          if (ret < 0 )
              goto out;
          if (data->pci_dev.num_virtual_functions > 0)
              data->pci_dev.flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VIRTUAL_FUNCTION;
      9a3ff01d
  12. 16 2月, 2013 1 次提交
    • E
      build: fix mingw build · 660db5bf
      Eric Blake 提交于
      Commits 20253560 and ba72cb12 introduced typos.
      
      * src/util/virpci.c (virPCIIsVirtualFunction) [!__linux__]: Fix
      function name.
      * src/util/virutil.c (virGetDeviceID): Fix attribute spelling.
      660db5bf
  13. 06 2月, 2013 2 次提交
  14. 11 1月, 2013 1 次提交
  15. 21 12月, 2012 5 次提交
  16. 05 12月, 2012 3 次提交
  17. 26 11月, 2012 1 次提交
  18. 02 11月, 2012 1 次提交
  19. 21 9月, 2012 1 次提交
  20. 31 8月, 2012 1 次提交
  21. 23 7月, 2012 1 次提交
    • O
      Desert the FSF address in copyright · f9ce7dad
      Osier Yang 提交于
      Per the FSF address could be changed from time to time, and GNU
      recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
      
        You should have received a copy of the GNU General Public License
        along with Foobar.  If not, see <http://www.gnu.org/licenses/>.
      
      This patch removes the explicit FSF address, and uses above instead
      (of course, with inserting 'Lesser' before 'General').
      
      Except a bunch of files for security driver, all others are changed
      automatically, the copyright for securify files are not complete,
      that's why to do it manually:
      
        src/security/security_selinux.h
        src/security/security_driver.h
        src/security/security_selinux.c
        src/security/security_apparmor.h
        src/security/security_apparmor.c
        src/security/security_driver.c
      f9ce7dad
  22. 18 7月, 2012 1 次提交
  23. 30 3月, 2012 1 次提交
  24. 09 3月, 2012 1 次提交
    • L
      util: consolidate duplicated error messages in pci.c · b8e47850
      Laine Stump 提交于
      This is nearly identical to an earlier patch for virnetlink.c.
      
      There are special stub versions of all public functions in this file
      that are compiled when the platform isn't linux. Each of these
      functions had an almost identical message, differing only in the
      function name included in the message. Since log messages already
      contain the function name, we can just define a const char* with the
      common part of the string, and use that same string for all the log
      messages.
      
      If nothing else, this at least makes for less strings that need
      translating...
      b8e47850