1. 26 9月, 2013 1 次提交
  2. 02 9月, 2013 1 次提交
  3. 29 8月, 2013 2 次提交
  4. 26 8月, 2013 4 次提交
  5. 22 8月, 2013 1 次提交
  6. 19 8月, 2013 1 次提交
    • M
      qemu: Drop qemuDomainMemoryLimit · 16bcb3b6
      Michal Privoznik 提交于
      This function is to guess the correct limit for maximal memory
      usage by qemu for given domain. This can never be guessed
      correctly, not to mention all the pains and sleepless nights this
      code has caused. Once somebody discovers algorithm to solve the
      Halting Problem, we can compute the limit algorithmically. But
      till then, this code should never see the light of the release
      again.
      16bcb3b6
  7. 13 8月, 2013 1 次提交
    • G
      Don't crash in qemuBuildDeviceAddressStr · bb97db2f
      Guido Günther 提交于
      qemuDomainAttachVirtioDiskDevice passes NULL as domainDef which is later
      referenced in qemuDomainAttachVirtioDiskDevice:
      
       Program terminated with signal 11, Segmentation fault.
       #0  qemuBuildDeviceAddressStr (buf=buf@entry=0xb646de78, info=info@entry=0xb0a02360, qemuCaps=qemuCaps@entry=0xb8fdfdc8,
           domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>,
           domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at qemu/qemu_command.c:2869
       2869            for (i = 0; i < domainDef->ncontrollers; i++) {
       (gdb) bt
       #0  qemuBuildDeviceAddressStr (buf=buf@entry=0xb646de78, info=info@entry=0xb0a02360, qemuCaps=qemuCaps@entry=0xb8fdfdc8,
           domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>,
           domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at qemu/qemu_command.c:2869
       #1  0xb18ad6f8 in qemuBuildDriveDevStr (def=def@entry=0x0, disk=disk@entry=0xb0a02288, bootindex=bootindex@entry=0, qemuCaps=0xb8fdfdc8)
           at qemu/qemu_command.c:4316
       #2  0xb18d097f in qemuDomainAttachVirtioDiskDevice (conn=conn@entry=0xb90129a8, driver=driver@entry=0xb8fe29b8, vm=vm@entry=0xb8fe0c40,
           disk=disk@entry=0xb0a02288) at qemu/qemu_hotplug.c:278
       #3  0xb193f7ba in qemuDomainAttachDeviceDiskLive (dev=0xb0a35308, vm=0xb8fe0c40, driver=0xb8fe29b8, conn=0xb90129a8) at qemu/qemu_driver.c:6356
       #4  qemuDomainAttachDeviceLive (dev=0xb0a35308, vm=0xb8fe0c40, dom=<optimized out>) at qemu/qemu_driver.c:6418
       #5  qemuDomainAttachDeviceFlags (dom=dom@entry=0xb0a020b8,
           xml=xml@entry=0xb90953f0 "<disk type='file' device='disk'>\n  <source file='/var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img'/>\n  <target dev='vdb' bus='virtio'/>\n</disk>\n", flags=3103664568, flags@entry=1) at qemu/qemu_driver.c:7079
       #6  0xb193f9cb in qemuDomainAttachDevice (dom=0xb0a020b8,
           xml=0xb90953f0 "<disk type='file' device='disk'>\n  <source file='/var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img'/>\n  <target dev='vdb' bus='virtio'/>\n</disk>\n") at qemu/qemu_driver.c:7120
       #7  0xb7244827 in virDomainAttachDevice (domain=domain@entry=0xb0a020b8,
           xml=0xb90953f0 "<disk type='file' device='disk'>\n  <source file='/var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img'/>\n  <target dev='vdb' bus='virtio'/>\n</disk>\n") at libvirt.c:10912
       #8  0xb7765ddb in remoteDispatchDomainAttachDevice (args=0xb9094ef0, rerr=0xb646e1f0, client=<optimized out>, server=<optimized out>,
           msg=<optimized out>) at remote_dispatch.h:2296
       #9  remoteDispatchDomainAttachDeviceHelper (server=0xb8fba0e8, client=0xb0a00730, msg=0xb0a350b8, rerr=0xb646e1f0, args=0xb9094ef0, ret=0xb9094dc8)
           at remote_dispatch.h:2274
       #10 0xb72b1013 in virNetServerProgramDispatchCall (msg=0xb0a350b8, client=0xb0a00730, server=0xb8fba0e8, prog=0xb8fc21c8)
           at rpc/virnetserverprogram.c:435
       #11 virNetServerProgramDispatch (prog=0xb8fc21c8, server=server@entry=0xb8fba0e8, client=0xb0a00730, msg=0xb0a350b8) at rpc/virnetserverprogram.c:305
       #12 0xb72aa167 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0xb8fba0e8)
           at rpc/virnetserver.c:165
       #13 virNetServerHandleJob (jobOpaque=0xb0a0a850, opaque=0xb8fba0e8) at rpc/virnetserver.c:186
       #14 0xb7189108 in virThreadPoolWorker (opaque=opaque@entry=0xb8fa3250) at util/virthreadpool.c:144
       #15 0xb71885e5 in virThreadHelper (data=0xb8fa32a8) at util/virthreadpthread.c:161
       #16 0xb70d6954 in start_thread (arg=0xb646eb70) at pthread_create.c:304
       #17 0xb704e95e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
      
      This was found by libvirtt-tck:
      
           http://honk.sigxcpu.org:8001/job/libvirt-tck-debian-wheezy-qemu-session/1311/console
      bb97db2f
  8. 08 8月, 2013 1 次提交
    • E
      qemu: Allow hotplug of multiple SCSI devices · c4eb1206
      Eric Farman 提交于
      Hotplugging a single SCSI device works, but adding additional ones
      result in an error from QEMU:
      
      [root@gpok197 ~]# virsh attach-device guest01 blah.xml
      Device attached successfully
      [root@gpok197 ~]# virsh attach-device guest01 blah2.xml
      error: Failed to attach device from blah2.xml
      error: internal error unable to execute QEMU command 'device_add': Duplicate ID 'hostdev0' for device
      
      The hostdev ID that is created is always set to zero, regardless
      of the contents of the XML.  Changing the index in the hotplug case
      to a negative one so the next available index is used.
      Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
      Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      c4eb1206
  9. 06 8月, 2013 1 次提交
    • L
      qemu: properly set/use device alias for pci controllers · 01b88127
      Laine Stump 提交于
      We had been setting the device alias in the devinceinfo for pci
      controllers to "pci%u", but then hardcoding "pci.%u" when creating the
      device address for other devices using that pci bus. This all worked
      just fine until we encountered the built-in "pcie.0" bus (the PCIe
      root complex) in Q35 machines.
      
      In order to create the correct commandline for this one case, this
      patch:
      
      1) sets the alias for PCI controllers correctly, to "pci.%u" (or
      "pcie.%u" for the pcie-root controller)
      
      2) eliminates the hardcoded "pci.%u" for pci controllers when
      generatuing device address strings, and instead uses the controller's
      alias.
      
      3) plumbs a pointer to the virDomainDef all the way down to
      qemuBuildDeviceAddressStr. This was necessary in order to make the
      aliase of the controller *used by a device* available (previously
      qemuBuildDeviceAddressStr only had the deviceinfo of the device
      itself, *not* of the controller it was connecting to). This made for a
      larger than desired diff, but at least in the future we won't have to
      do it again, since all the information we could possibly ever need for
      future enhancements is in the virDomainDef. (right?)
      
      This should be done for *all* controllers, but for now we just do it
      in the case of PCI controllers, to reduce the likelyhood of
      regression.
      01b88127
  10. 18 7月, 2013 4 次提交
  11. 17 7月, 2013 6 次提交
  12. 16 7月, 2013 2 次提交
    • M
      qemu: Implement chardev hotplug on live level · 24b08219
      Michal Privoznik 提交于
      Since previous patches has prepared everything for us, we may now
      implement live hotplug of a character device.
      24b08219
    • M
      qemu: Implement chardev hotplug on config level · 75f0fd51
      Michal Privoznik 提交于
      There are two levels on which a device may be hotplugged: config
      and live. The config level requires just an insert or remove from
      internal domain definition structure, which is exactly what this
      patch does. There is currently no implementation for a chardev
      update action, as there's not much to be updated. But more
      importantly, the only thing that can be updated is path or socket
      address by which chardevs are distinguished. So the update action
      is currently not supported.
      75f0fd51
  13. 15 7月, 2013 2 次提交
    • M
      qemu: add macvlan delete to qemuDomainAttachNetDevice cleanup · 97f97a49
      Matthew Rosato 提交于
      If an error occurs during qemuDomainAttachNetDevice after the macvtap
      was created in qemuPhysIfaceConnect, the macvtap device gets left behind.
      This patch adds code to the cleanup routine to delete the macvtap.
      Signed-off-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
      Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      97f97a49
    • L
      pci: make virPCIDeviceReset more autonomous · 9e37f57f
      Laine Stump 提交于
      I recently patches the callers to virPCIDeviceReset() to not call it
      if the current driver for a device was vfio-pci (since that driver
      will always reset the device itself when appropriate. At the time, Dan
      Berrange suggested that I could instead modify virPCIDeviceReset
      to check the currently bound driver for the device, and decide
      for itself whether or not to go ahead with the reset.
      
      This patch removes the previously added checks, and replaces them with
      a check down in virPCIDeviceReset(), as suggested.
      
      The functional difference here is that previously we were deciding
      based on either the hostdev configuration or the value of
      stubDriverName in the virPCIDevice object, but now we are actually
      comparing to the "driver" link in the device's sysfs entry
      directly. In practice, both should be the same.
      9e37f57f
  14. 11 7月, 2013 1 次提交
  15. 10 7月, 2013 1 次提交
  16. 08 7月, 2013 1 次提交
  17. 25 6月, 2013 1 次提交
    • L
      qemu: don't reset PCI devices being assigned with VFIO · 1eeab6e6
      Laine Stump 提交于
      I just learned that VFIO resets PCI devices when they are assigned to
      guests / returned to the host, so it is redundant for libvirt to reset
      the devices. This patch inhibits calling virPCIDeviceReset to devices
      that will be/were assigned using VFIO.
      1eeab6e6
  18. 21 6月, 2013 2 次提交
    • J
      build: Fix build with -Werror · 24d0e67a
      Jim Fehlig 提交于
      Commit 752596b5 broke the build with -Werror
      
      qemu/qemu_hotplug.c: In function 'qemuDomainChangeGraphics':
      qemu/qemu_hotplug.c:1980:39: error: declaration of 'listen' shadows a
        global declaration [-Werror=shadow]
      
      Fix with s/listen/newlisten/
      24d0e67a
    • M
      qemuDomainChangeGraphics: Check listen address change by listen type · 752596b5
      Michal Privoznik 提交于
      Currently, we have a bug when updating a graphics device. A graphics device can
      have a listen address set. This address is either defined by user (in which case
      it's type is VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_ADDRESS) or it can be inherited
      from a network (in which case it's type is
      VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NETWORK). However, in both cases we have a
      listen address to process (e.g. during migration, as I've tried to fix in
      7f15ebc7).
      Later, when a user tries to update the graphics device (e.g. set a password),
      we check if listen addresses match the original as qemu doesn't know how to
      change listen address yet. Hence, users are required to not change the listen
      address. The implementation then just dumps listen addresses and compare them.
      Previously, while dumping the listen addresses, NULL was returned for NETWORK.
      After my patch, this is no longer true, and we get a listen address for olddev
      even if it is a type of NETWORK. So we have a real string on one side, the NULL
      from user's XML on the other side and hence we think user wants to change the
      listen address and we refuse it.
      
      Therefore, we must take the type of listen address into account as well.
      752596b5
  19. 28 5月, 2013 1 次提交
    • C
      qemu: Don't report error on successful media eject · 406d8a98
      Cole Robinson 提交于
      If we are just ejecting media, ret == -1 even after the retry loop
      determines that the tray is open, as requested. This means media
      disconnect always report's error.
      
      Fix it, and fix some other mini issues:
      
      - Don't overwrite the 'eject' error message if the retry loop fails
      - Move the retries decrement inside the loop, otherwise the final loop
        might succeed, yet retries == 0 and we will raise error
      - Setting ret = -1 in the disk->src check is unneeded
      - Fix comment typos
      
      cc: mprivozn@redhat.com
      406d8a98
  20. 23 5月, 2013 1 次提交
  21. 22 5月, 2013 2 次提交
    • M
      qemu: Enable multiqueue network · 03eb0663
      Michal Privoznik 提交于
      03eb0663
    • M
      qemu: Adapt qemuBuildInterfaceCommandLine to to multiqueue net · 1f24f682
      Michal Privoznik 提交于
      In order to learn libvirt multiqueue several things must be done:
      
      1) The '/dev/net/tun' device needs to be opened multiple times with
      IFF_MULTI_QUEUE flag passed to ioctl(fd, TUNSETIFF, &ifr);
      
      2) Similarly, '/dev/vhost-net' must be opened as many times as in 1)
      in order to keep 1:1 ratio recommended by qemu and kernel folks.
      
      3) The command line construction code needs to switch from 'fd=X' to
      'fds=X:Y:...:Z' and from 'vhostfd=X' to 'vhostfds=X:Y:...:Z'.
      
      4) The monitor handling code needs to learn to pass multiple FDs.
      1f24f682
  22. 21 5月, 2013 2 次提交
    • O
      src/qemu: Remove the whitespace before ';' · 66194f71
      Osier Yang 提交于
      66194f71
    • M
      qemuDomainChangeEjectableMedia: Unlock domain while waiting for event · 543af79a
      Michal Privoznik 提交于
      In 84c59ffa I've tried to fix changing ejectable media process. The
      process should go like this:
      
      1) we need to call 'eject' on the monitor
      2) we should wait for 'DEVICE_TRAY_MOVED' event
      3) now we can issue 'change' command
      
      However, while waiting in step 2) the domain monitor was locked. So
      even if qemu reported the desired event, the proper callback was not
      called immediately. The monitor handling code needs to lock the
      monitor in order to read the event. So that's the first lock we must
      not hold while waiting. The second one is the domain lock. When
      monitor handling code reads an event, the appropriate callback is
      called then. The first thing that each callback does is locking the
      corresponding domain as a domain or its device is about to change
      state. So we need to unlock both monitor and VM lock. Well, holding
      any lock while sleep()-ing is not the best thing to do anyway.
      543af79a
  23. 20 5月, 2013 1 次提交
    • O
      qemu: Add callback struct for qemuBuildCommandLine · 3a6204cb
      Osier Yang 提交于
      Since 0d70656a, it starts to access the sysfs files to build
      the qemu command line (by virSCSIDeviceGetSgName, which is to find
      out the scsi generic device name by adpater:bus:target:unit), there
      is no way to work around, qemu wants to see the scsi generic device
      like "/dev/sg6" anyway.
      
      And there might be other places which need to access sysfs files
      when building qemu command line in future.
      
      Instead of increasing the arguments of qemuBuildCommandLine, this
      introduces a new callback for qemuBuildCommandLine, and thus tests
      can register their own callbacks for sysfs test input files accessing.
      
      * src/qemu/qemu_command.h: (New callback struct
                                  qemuBuildCommandLineCallbacks;
                                  extern buildCommandLineCallbacks)
      * src/qemu/qemu_command.c: (wire up the callback struct)
      * src/qemu/qemu_driver.c: (Use the new syntax of qemuBuildCommandLine)
      * src/qemu/qemu_hotplug.c: Likewise
      * src/qemu/qemu_process.c: Likewise
      * tests/testutilsqemu.[ch]: (Helper testSCSIDeviceGetSgName;
                                   callback struct testCallbacks;)
      * tests/qemuxml2argvtest.c: (Use testCallbacks)
      * src/tests/qemuxmlnstest.c: (Like above)
      3a6204cb