1. 05 6月, 2017 3 次提交
  2. 03 6月, 2017 10 次提交
  3. 29 5月, 2017 1 次提交
    • M
      virCapabilitiesInitCaches: Don't leak @cpus · 6e9e1423
      Michal Privoznik 提交于
      The @cpus is allocated by virFileReadValueBitmap() but never
      freed:
      
      ==21274== 40 (32 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 808 of 1,004
      ==21274==    at 0x4C2E080: calloc (vg_replace_malloc.c:711)
      ==21274==    by 0x54BA561: virAlloc (viralloc.c:144)
      ==21274==    by 0x54BC604: virBitmapNewEmpty (virbitmap.c:126)
      ==21274==    by 0x54BD059: virBitmapParseUnlimited (virbitmap.c:570)
      ==21274==    by 0x54EECE9: virFileReadValueBitmap (virfile.c:4113)
      ==21274==    by 0x5563132: virCapabilitiesInitCaches (capabilities.c:1548)
      ==21274==    by 0x2BB86E59: virQEMUCapsInit (qemu_capabilities.c:1132)
      ==21274==    by 0x2BBEC067: virQEMUDriverCreateCapabilities (qemu_conf.c:928)
      ==21274==    by 0x2BC3DEAA: qemuStateInitialize (qemu_driver.c:845)
      ==21274==    by 0x5625AAC: virStateInitialize (libvirt.c:770)
      ==21274==    by 0x124519: daemonRunStateInit (libvirtd.c:881)
      ==21274==    by 0x554C927: virThreadHelper (virthread.c:206)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      6e9e1423
  4. 26 5月, 2017 4 次提交
  5. 25 5月, 2017 1 次提交
  6. 24 5月, 2017 3 次提交
  7. 22 5月, 2017 1 次提交
  8. 19 5月, 2017 1 次提交
  9. 18 5月, 2017 4 次提交
    • E
      nodedev: Introduce mdev capability for mediated devices · 88ef73e1
      Erik Skultety 提交于
      Start discovering the mediated devices on the host system and format the
      attributes for the mediated device into the XML. Compared to the parent
      device which reports generic information about the abstract mediated
      devices types, a child device only reports the type name it has been
      instantiated from and the IOMMU group number, since that's device
      specific compared to the rest of the info that can be gathered about
      mediated devices at the moment.
      This patch introduces both the formatting and parsing routines, updates
      nodedev.rng schema, adding a testcase as well.
      
      The resulting mdev child device XML:
      <device>
        <name>mdev_4b20d080_1b54_4048_85b3_a6a62d165c01</name>
        <path>/sys/devices/.../4b20d080-1b54-4048-85b3-a6a62d165c01</path>
        <parent>pci_0000_06_00_0</parent>
        <driver>
          <name>vfio_mdev</name>
        </driver>
        <capability type='mdev'>
          <type id='vendor_supplied_type_id'/>
          <iommuGroup number='NUM'/>
        <capability/>
      <device/>
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>
      88ef73e1
    • E
      nodedev: Introduce the mdev capability to a PCI parent device · 500cbc06
      Erik Skultety 提交于
      The parent device needs to report the generic stuff about the supported
      mediated devices types, like device API, available instances, type name,
      etc. Therefore this patch introduces a new nested capability element of
      type 'mdev_types' with the resulting XML of the following format:
      
      <device>
        ...
        <capability type='pci'>
          ...
          <capability type='mdev_types'>
            <type id='vendor_supplied_id'>
              <name>optional_vendor_supplied_codename</name>
              <deviceAPI>vfio-pci</deviceAPI>
              <availableInstances>NUM</availableInstances>
            </type>
              ...
            <type>
              ...
            </type>
          </capability>
        </capability>
        ...
      </device>
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>
      500cbc06
    • E
      nodedev: Introduce new mdev_types and mdev nodedev capabilities · 4385df97
      Erik Skultety 提交于
      The reason for introducing two capabilities, one for the device itself
      (cap 'mdev') and one for the parent device listing the available types
      ('mdev_types'), is that we should be able to do
      'virsh nodedev-list --cap' not only for existing mdev devices but also
      for devices that support creation of mdev devices, since one day libvirt
      might be actually able to create the mdev devices in an automated way
      (just like we do for NPIV/vHBA).
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>
      4385df97
    • E
      nodedev: conf: Split PCI sub-capability parsing to separate methods · a5c1f3b7
      Erik Skultety 提交于
      Since there's at least SRIOV and MDEV sub-capabilities to be parsed,
      let's make the code more readable by splitting it to several logical
      blocks.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      a5c1f3b7
  10. 15 5月, 2017 5 次提交
  11. 12 5月, 2017 1 次提交
    • J
      conf: Fix resource leak in virCapabilitiesInitCaches · d6128618
      John Ferlan 提交于
      The @type from virFileReadValueString needs to be VIR_FREE each time
      through the loop since it's not saved and since cleanup can be reached
      prior to decoding it for @kernel_type amd bank->type, the cleanup code
      needs to also have a VIR_FREE
      
      Found by Coverity
      d6128618
  12. 10 5月, 2017 1 次提交
  13. 09 5月, 2017 2 次提交
  14. 05 5月, 2017 1 次提交
    • M
      virNWFilterObjListFree: Don't leak nwfilters->objs · 772e4247
      Michal Privoznik 提交于
      When adding a nwfilter onto the list in
      virNWFilterObjListAssignDef() this array is re-allocated to match
      demand for new size. However, it is never freed leading to a
      leak:
      
      ==26535== 136 bytes in 1 blocks are definitely lost in loss record 1,079 of 1,250
      ==26535==    at 0x4C2E2BE: realloc (vg_replace_malloc.c:785)
      ==26535==    by 0x54BA28E: virReallocN (viralloc.c:245)
      ==26535==    by 0x54BA384: virExpandN (viralloc.c:294)
      ==26535==    by 0x54BA657: virInsertElementsN (viralloc.c:436)
      ==26535==    by 0x55DB011: virNWFilterObjListAssignDef (virnwfilterobj.c:362)
      ==26535==    by 0x55DB530: virNWFilterObjListLoadConfig (virnwfilterobj.c:503)
      ==26535==    by 0x55DB635: virNWFilterObjListLoadAllConfigs (virnwfilterobj.c:539)
      ==26535==    by 0x2AC5A28B: nwfilterStateInitialize (nwfilter_driver.c:250)
      ==26535==    by 0x5621C64: virStateInitialize (libvirt.c:770)
      ==26535==    by 0x124379: daemonRunStateInit (libvirtd.c:881)
      ==26535==    by 0x554AC78: virThreadHelper (virthread.c:206)
      ==26535==    by 0x8F5F493: start_thread (in /lib64/libpthread-2.23.so)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      772e4247
  15. 28 4月, 2017 2 次提交
    • L
      util: rename/move VIR_NET_GENERATED_PREFIX to be consistent · 30e67230
      Laine Stump 提交于
      ... with VIR_NET_GENERATED_MACV???_PREFIX, which is defined in
      util/virnetdevmacvlan.h.
      
      Since VIR_NET_GENERATED_PREFIX is used for plain tap devices, it is
      renamed to VIR_NET_GENERATED_TAP_PREFIX and moved to virnetdev.h
      30e67230
    • L
      conf: don't ignore <target dev='blah'/> for macvtap interfaces · 9cb89114
      Laine Stump 提交于
      The parser had been clearing out *all* suggested device names for
      type='direct' (aka macvtap) interfaces. All of the code implementing
      macvtap allows for a user-specified device name, so we should allow
      it. In the case that an interface name starts with "macvtap" or
      "macvlan" though, we do still clear it out, just as we do with "vnet"
      (which is the prefix used for automatically generated tap device
      names), since those are the prefixes for the names we autogenerate for
      macvtap and macvlan devices.
      
      Resolves: https://bugzilla.redhat.com/1335798
      9cb89114