1. 04 1月, 2016 1 次提交
    • M
      qemu: do not copy out non-existent block job info · 1b43885d
      Michael Chapman 提交于
      Valgrind complained:
      
      ==23975== Conditional jump or move depends on uninitialised value(s)
      ==23975==    at 0x22255FA6: qemuDomainGetBlockJobInfo (qemu_driver.c:16538)
      ==23975==    by 0x538E97C: virDomainGetBlockJobInfo (libvirt-domain.c:9685)
      ==23975==    by 0x12F740: remoteDispatchDomainGetBlockJobInfoHelper (remote.c:2834)
      ==23975==    by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437)
      ==23975==    by 0x540523D: virNetServerProcessMsg (virnetserver.c:135)
      ==23975==    by 0x54052C7: virNetServerHandleJob (virnetserver.c:156)
      ==23975==    by 0x52F515B: virThreadPoolWorker (virthreadpool.c:145)
      ==23975==    by 0x52F4668: virThreadHelper (virthread.c:206)
      ==23975==    by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so)
      ==23975==    by 0x82BE93C: clone (in /lib64/libc-2.12.so)
      ==23975==
      ==23975== Conditional jump or move depends on uninitialised value(s)
      ==23975==    at 0x22255FB4: qemuDomainGetBlockJobInfo (qemu_driver.c:16542)
      ==23975==    by 0x538E97C: virDomainGetBlockJobInfo (libvirt-domain.c:9685)
      ==23975==    by 0x12F740: remoteDispatchDomainGetBlockJobInfoHelper (remote.c:2834)
      ==23975==    by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437)
      ==23975==    by 0x540523D: virNetServerProcessMsg (virnetserver.c:135)
      ==23975==    by 0x54052C7: virNetServerHandleJob (virnetserver.c:156)
      ==23975==    by 0x52F515B: virThreadPoolWorker (virthreadpool.c:145)
      ==23975==    by 0x52F4668: virThreadHelper (virthread.c:206)
      ==23975==    by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so)
      ==23975==    by 0x82BE93C: clone (in /lib64/libc-2.12.so)
      
      If no matching block job is found, qemuMonitorGetBlockJobInfo returns 0
      and we should not write anything to the caller-supplied
      virDomainBlockJobInfo pointer.
      Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
      1b43885d
  2. 29 12月, 2015 1 次提交
  3. 25 12月, 2015 4 次提交
    • M
      tools: Disable virt-login-shell on mingw · 7bf3c13d
      Michal Privoznik 提交于
      So, after bec787ee we are building virt-login-shell
      independent of LXC driver. This is nice, but the binary is
      enabled by default which makes no sense on mingw. In fact, it
      triggers some compilation errors there:
      
        CC       virt_login_shell-virt-login-shell.o
      ../../tools/virt-login-shell.c: In function 'main':
      ../../tools/virt-login-shell.c:289:15: error: implicit declaration of function 'sysconf' [-Werror=implicit-function-declaration]
           openmax = sysconf(_SC_OPEN_MAX);
                     ^
      ../../tools/virt-login-shell.c:289:5: error: nested extern declaration of 'sysconf' [-Werror=nested-externs]
           openmax = sysconf(_SC_OPEN_MAX);
           ^
      ../../tools/virt-login-shell.c:289:23: error: '_SC_OPEN_MAX' undeclared (first use in this function)
           openmax = sysconf(_SC_OPEN_MAX);
                             ^
      ../../tools/virt-login-shell.c:289:23: note: each undeclared identifier is reported only once for each function it appears in
      cc1: all warnings being treated as errors
      
      While we could workaround sysconf(_SC_OPEN_MAX) issue, the binary
      itself makes no sense on systems where no LXC can be spawned.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      7bf3c13d
    • M
      tools: Include PIE_LDFLAGS at the correct place · 0059848e
      Michal Privoznik 提交于
      This is no functional change, but I find it disturbing that
      something_LDADD contains PIE_LDFLAGS while something_LDFLAGS
      doesn't.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      0059848e
    • M
      sysconf: Include unistd.h · f55d1316
      Michal Privoznik 提交于
      The manpage for sysconf() suggest including unistd.h as the
      function is declared there. Even though we are not hitting any
      compile issues currently, let's include the correct header file
      instead of relying on some hidden include chain.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      f55d1316
    • M
      virStorageVolWipe: Document that wiping journaled FS is useless · eec91958
      Michal Privoznik 提交于
      So you have a libvirt volume that you want to wipe out. But lets
      say that the volume is actually a file stored on a journaled
      filesystem. Overwriting it with zeroes or a pattern does not mean
      that corresponding physical location on the disk is overwritten
      too, due to journaling. It's the same story with network based
      volumes, copy-on-write filesystems, and so on. Since there is no
      way that an userland application can write onto specific areas on
      disk, all that we can do is document the fact.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      eec91958
  4. 24 12月, 2015 7 次提交
  5. 21 12月, 2015 7 次提交
    • A
      hostdev: Emit debug messages while handling PCI hostdevs · d5a0cf10
      Andrea Bolognani 提交于
      Both detach and reattach are complex operations involving several steps,
      and it can be useful to be able to follow along by reading the log.
      d5a0cf10
    • A
      hostdev: Only rollback detach of managed devices on error · e926df60
      Andrea Bolognani 提交于
      Since we don't detach unmanaged devices before attaching them to a
      domain, we shouldn't reattach them to rollback an error either.
      e926df60
    • A
      hostdev: Mark PCI devices as inactive as they're detached · b8a625f3
      Andrea Bolognani 提交于
      We want to eventually factor out the code dealing with device detaching
      and reattaching, so that we can share it and make sure it's called eg.
      when 'virsh nodedev-detach' is used.
      
      For that to happen, it's important that the lists of active and inactive
      PCI devices are updated every time a device changes its state.
      
      Instead of passing NULL as the last argument of virPCIDeviceDetach() and
      virPCIDeviceReattach(), pass the proper list so that it can be updated.
      b8a625f3
    • A
      pci: Introduce virPCIStubDriver enumeration · 6d9cdd2a
      Andrea Bolognani 提交于
      This replaces the virPCIKnownStubs string array that was used
      internally for stub driver validation.
      
      Advantages:
      
        * possible values are well-defined
        * typos in driver names will be detected at compile time
        * avoids having several copies of the same string around
        * no error checking required when setting / getting value
      
      The names used mirror those in the
      virDomainHostdevSubsysPCIBackendType enumeration.
      6d9cdd2a
    • A
      pci: Remove 'reprobe' parameter from virPCIDeviceUnbind() · e1b24583
      Andrea Bolognani 提交于
      The value is not inspected inside the function, so it makes more
      sense for the caller to change the device's setting explicitly.
      e1b24583
    • A
      pci: Remove redundant parameter from virPCIDeviceBindToStub() · 51f39c70
      Andrea Bolognani 提交于
      This internal function supports, in theory, binding to a different
      stub driver than the one the PCI device has been configured to use.
      
      In practice, it is only ever called like
      
        virPCIDeviceBindToStub(dev, dev->stubDriver);
      
      which makes its second parameter redundant. Get rid of it, along
      with the extra string copy required to support it.
      51f39c70
    • E
      Revert "admin: Rename virAdmConnect to virAdmDaemon" · 3245e178
      Erik Skultety 提交于
      Commmit df8192aa introduced admin related rename and some minor
      (caused by automated approach, aka sed) and some more severe isues along with
      it. First reason to revert is the inconsistency with libvirt library.
      Although we deal with the daemon directly rather than with a specific
      hypervisor, we still do have a connection. That being said, contributors might
      get under the impression that AdmDaemonNew would spawn/start a new daemon
      (since it's admin API, why not...), or AdmDaemonClose would do the exact
      opposite or they might expect DaemonIsAlive report overall status of the daemon
      which definitely isn't the case.
      The second reason to revert this patch is renaming virt-admin client. The
      client tool does not necessarily have to reflect the names of the API's it's
      using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon'
      where noone can be certain of what the latter function really does. The former
      is quite expressive about some connection magic it performs, but the latter does
      not say anything, especially when vshAdmReconnect and vshAdmDisconnect were
      left untouched.
      3245e178
  6. 19 12月, 2015 1 次提交
    • J
      Xen: support maxvcpus in xm and xl config · 5b74103b
      Jim Fehlig 提交于
      From: Ian Campbell <ian.campbell@citrix.com>
      
      xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
      as a bit map of which cpus are online (default is all).
      
      xend from 4.0 onwards understands maxvcpus as maxvcpus and
      vcpus as the number which are online (from 0..N-1). The
      upstream commit (68a94cf528e6 "xm: Add maxvcpus support")
      claims that if maxvcpus is omitted then the old behaviour
      (i.e. obeying vcpu_avail) is retained, but AFAICT it was not,
      in this case vcpu==maxcpus==online cpus. This is good for us
      because handling anything else would be fiddly.
      
      This patch changes parsing of the virDomainDef maxvcpus and vcpus
      entries to use the corresponding 'maxvcpus' and 'vcpus' settings
      from xm and xl config. It also drops use of the old Xen 3.x
      'vcpu_avail' setting.
      
      The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since
      maxvcpus is simply a count, not a bit mask), which is particularly
      crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are
      expected to support vcpu placement, and therefore only the boot
      vcpu's info lives in the shared info page).
      
      Existing tests adjusted accordingly, and new tests added for the
      'maxvcpus' setting.
      5b74103b
  7. 18 12月, 2015 19 次提交