1. 02 10月, 2014 1 次提交
  2. 18 9月, 2014 1 次提交
  3. 03 7月, 2014 2 次提交
    • P
      qemu: copy: Accept 'format' parameter when copying to a non-existing img · 17df6a9b
      Peter Krempa 提交于
      We have the following matrix of possible arguments handled by the logic
      statement touched by this patch:
             | flags & _REUSE_EXT | !(flags & _REUSE_EXT)
      -------+--------------------+----------------------
       format| (1)                | (2)
      -------+--------------------+----------------------
      !format| (3)                | (4)
      -------+--------------------+----------------------
      
      In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The
      user requests to use a pre-existing image in 1 and 3 and libvirt will
      create a new image in 2 and 4.
      
      The difference between cases 3 and 4 is that for 3 the format is probed
      from the user-provided image, whereas in 4 we just use the existing disk
      format.
      
      The current code would treat cases 1,3 and 4 correctly but in case 2 the
      format provided by the user would be ignored.
      
      The particular piece of code was broken in commit 35c7701c
      but since it was introduced a few commits before that it was never
      released as working.
      
      (cherry picked from commit 42619ed0)
      Signed-off-by: NEric Blake <eblake@redhat.com>
      
      Conflicts:
      	src/qemu/qemu_driver.c - no refactoring of commits 7b7bf001, 4f202266
      17df6a9b
    • E
      build: fix 'make check' with newer git · d528a5e0
      Eric Blake 提交于
      Newer git doesn't like the maint.mk rule 'public-submodule-commit'
      run during 'make check', as inherited from our checkout of gnulib.
      I tracked down that libvirt commit 8531301d picked up a gnulib fix
      that makes git happy.  Rather than try and do a full .gnulib
      submodule update to gnulib.git d18d1b802 (as used in that libvirt
      commit), it was easier to just backport the fixed maint.mk from
      gnulib on top of our existing submodule level.  I did it as follows,
      where these steps will have to be repeated when cherry-picking this
      commit to any other maintenance branch:
      
      mkdir -p gnulib/local/top
      cd .gnulib
      git checkout d18d1b802 top/maint.mk
      git diff HEAD > ../gnulib/local/top/maint.mk.diff
      git reset --hard
      cd ..
      git add gnulib/local/top
      Signed-off-by: NEric Blake <eblake@redhat.com>
      d528a5e0
  4. 27 6月, 2014 2 次提交
    • E
      docs: publish correct enum values · ceefdec9
      Eric Blake 提交于
      We publish libvirt-api.xml for others to use, and in fact, the
      libvirt-python bindings use it to generate python constants that
      correspond to our enum values.  However, we had an off-by-one bug
      that any enum that relied on C's rules for implicit initialization
      of the first enum member to 0 got listed in the xml as having a
      value of 1 (and all later members of the enum were equally
      botched).
      
      The fix is simple - since we add one to the previous value when
      encountering an enum without an initializer, the previous value
      must start at -1 so that the first enum member is assigned 0.
      
      The python generator code has had the off-by-one ever since DV
      first wrote it years ago, but most of our public enums were immune
      because they had an explicit = 0 initializer.  The only affected
      enums are:
      - virDomainEventGraphicsAddressType (such as
      VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31ed
      (libvirt v0.8.0)
      - virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
      since commit 9fbaff00 (libvirt v1.2.3)
      - virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
      03e0e79e (not yet released)
      
      Thanks to Nehal J Wani for reporting the problem on IRC, and
      for helping me zero in on the culprit function.
      
      * docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
      values.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 9b291bbe)
      
      Conflicts:
      	docs/apibuild.py - context with 2a409511
      ceefdec9
    • P
      qemu: blockcopy: Don't remove existing disk mirror info · 39b5123d
      Peter Krempa 提交于
      When creating a new disk mirror the new struct is stored in a separate
      variable until everything went well. The removed hunk would actually
      remove existing mirror information for example when the api would be run
      if a mirror still exists.
      
      (cherry picked from commit 02b364e1)
      
      This fixes a regression introduced in commit ff5f30b6.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      
      Conflicts:
      	src/qemu/qemu_driver.c - no refactoring of commits 7b7bf001, 4f202266, a88fb300
      39b5123d
  5. 06 5月, 2014 1 次提交
  6. 05 5月, 2014 1 次提交
    • J
      libxl: fix framebuffer port setting for HVM domains · 05afc985
      Jim Fehlig 提交于
      libxl uses the libxl_vnc_info and libxl_sdl_info fields from the
      hvm union in libxl_domain_build_info struct when generating QEMU
      args for VNC or SDL.  These fields were left unset by the libxl
      driver, causing libxl to ignore any user settings.  E.g. with
      
        <graphics type='vnc' port='5950'/>
      
      port would be ignored and QEMU would instead be invoked with
      
        -vnc 127.0.0.1:0,to=99
      
      Unlike the libxl_domain_config struct, the libxl_domain_build_info
      contains only a single libxl_vnc_info and libxl_sdl_info, so
      populate these fields from the first vfb in
      libxl_domain_config->vfbs.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Signed-off-by: NDavid Kiarie <davidkiarie4@gmail.com>
      (cherry picked from commit b55cc5f4)
      05afc985
  7. 03 5月, 2014 1 次提交
  8. 01 5月, 2014 1 次提交
  9. 10 4月, 2014 4 次提交
  10. 20 3月, 2014 1 次提交
    • M
      virNetClientSetTLSSession: Restore original signal mask · 6b48d5e6
      Michal Privoznik 提交于
      Currently, we use pthread_sigmask(SIG_BLOCK, ...) prior to calling
      poll(). This is okay, as we don't want poll() to be interrupted.
      However, then - immediately as we fall out from the poll() - we try to
      restore the original sigmask - again using SIG_BLOCK. But as the man
      page says, SIG_BLOCK adds signals to the signal mask:
      
      SIG_BLOCK
            The set of blocked signals is the union of the current set and the set argument.
      
      Therefore, when restoring the original mask, we need to completely
      overwrite the one we set earlier and hence we should be using:
      
      SIG_SETMASK
            The set of blocked signals is set to the argument set.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit 3d4b4f5a)
      6b48d5e6
  11. 10 3月, 2014 1 次提交
    • D
      Add a mutex to serialize updates to firewall · 78c35ad5
      Daniel P. Berrange 提交于
      The nwfilter conf update mutex previously serialized
      updates to the internal data structures for firewall
      rules, and updates to the firewall itself. The latter
      was recently turned into a read/write lock, and filter
      instantiation allowed to proceed in parallel. It was
      believed that this was ok, since each filter is created
      on a separate iptables/ebtables chain.
      
      It turns out that there is a subtle lock ordering problem
      on virNWFilterObjPtr instances. __virNWFilterInstantiateFilter
      will hold a lock on the virNWFilterObjPtr it is instantiating.
      This in turn invokes virNWFilterInstantiate which then invokes
      virNWFilterDetermineMissingVarsRec which then invokes
      virNWFilterObjFindByName. This iterates over every single
      virNWFilterObjPtr in the list, locking them and checking their
      name. So if 2 or more threads try to instantiate a filter in
      parallel, they'll all hold 1 lock at the top level in the
      __virNWFilterInstantiateFilter method which will cause the
      other thread to deadlock in virNWFilterObjFindByName.
      
      The fix is to add an exclusive mutex to serialize the
      execution of __virNWFilterInstantiateFilter.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 925de19e)
      
      Conflicts:
      	src/nwfilter/nwfilter_gentech_driver.c
      78c35ad5
  12. 19 2月, 2014 22 次提交
  13. 06 2月, 2014 2 次提交
    • D
      Push nwfilter update locking up to top level · 419ea630
      Daniel P. Berrange 提交于
      The NWFilter code has as a deadlock race condition between
      the virNWFilter{Define,Undefine} APIs and starting of guest
      VMs due to mis-matched lock ordering.
      
      In the virNWFilter{Define,Undefine} codepaths the lock ordering
      is
      
        1. nwfilter driver lock
        2. virt driver lock
        3. nwfilter update lock
        4. domain object lock
      
      In the VM guest startup paths the lock ordering is
      
        1. virt driver lock
        2. domain object lock
        3. nwfilter update lock
      
      As can be seen the domain object and nwfilter update locks are
      not acquired in a consistent order.
      
      The fix used is to push the nwfilter update lock upto the top
      level resulting in a lock ordering for virNWFilter{Define,Undefine}
      of
      
        1. nwfilter driver lock
        2. nwfilter update lock
        3. virt driver lock
        4. domain object lock
      
      and VM start using
      
        1. nwfilter update lock
        2. virt driver lock
        3. domain object lock
      
      This has the effect of serializing VM startup once again, even if
      no nwfilters are applied to the guest. There is also the possibility
      of deadlock due to a call graph loop via virNWFilterInstantiate
      and virNWFilterInstantiateFilterLate.
      
      These two problems mean the lock must be turned into a read/write
      lock instead of a plain mutex at the same time. The lock is used to
      serialize changes to the "driver->nwfilters" hash, so the write lock
      only needs to be held by the define/undefine methods. All other
      methods can rely on a read lock which allows good concurrency.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 6e5c79a1)
      
      Conflicts:
      	src/conf/nwfilter_conf.c
                - virReportOOMError() in context of one hunk.
      	src/lxc/lxc_driver.c
                - functions renamed, and lxc object locking changed, creating
                  a conflict in the context.
      419ea630
    • D
      Add a read/write lock implementation · 75965943
      Daniel P. Berrange 提交于
      Add virRWLock backed up by a POSIX rwlock primitive
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit c065984b)
      75965943