1. 20 Oct, 2014 1 commit
  2. 25 Sep, 2014 1 commit
    • Markus Armbruster's avatar
      block: Keep DriveInfo alive until BlockDriverState dies · 3ae59580
      Markus Armbruster authored
      If the BDS's refcnt > 0, drive_del() destroys the DriveInfo, but not
      the BDS.  This can happen in three places:
      * Device model destruction during unplug: blockdev_auto_del()
      * Xen IDE unplug: pci_piix3_xen_ide_unplug()
      * drive_del command when no device model is attached: do_drive_del()
      The other callers of drive_del are on error paths where refcnt == 1.
      If the user somehow manages to plug in a device model using a BDS that
      has gone through drive_del(), the legacy configuration passed in
      DriveInfo doesn't reach the device model, and automatic deletion on
      unplug doesn't work.  Worse, some device models such as scsi-disk
      crash when DriveInfo doesn't exist.
      This is theoretical; I didn't research an actual reproducer. The problem
      was introduced when we replaced DriveInfo reference counting by BDS
      reference counting in commit a94a3fac..fa510ebf.
      Fix by keeping DriveInfo alive until its BDS dies.
      This affects qemu_drive_opts: now you can't reuse the same ID for new
      drive options until the BDS dies.  Before, you could, but since the
      code always attempts to create a BDS with the same ID next, the
      enclosing operation "create a new drive" failed anyway.  Different
      error path, same result.
      Unfortunately, the fix involves use of blockdev.c stuff from block.c,
      which is a layering violation.  Fortunately, my forthcoming
      BlockBackend work will get rid of it again.
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
      Reviewed-by: default avatarBenoît Canet <benoit.canet@nodalink.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
  3. 18 Aug, 2014 1 commit
  4. 06 Aug, 2014 1 commit
    • Paolo Bonzini's avatar
      backends: Introduce chr-testdev · 5692399f
      Paolo Bonzini authored
      From: Paolo Bonzini <pbonzini@redhat.com>
      chr-testdev enables a virtio serial channel to be used for guest
      initiated qemu exits. hw/misc/debugexit already enables guest
      initiated qemu exits, but only for PC targets. chr-testdev supports
      any virtio-capable target. kvm-unit-tests/arm is already making use
      of this backend.
      Currently there is a single command implemented, "q".  It takes a
      (prefix) argument for the exit code, thus an exit is implemented by
      writing, e.g. "1q", to the virtio-serial port.
      It can be used as:
         $QEMU ... \
           -device virtio-serial-device \
           -device virtserialport,chardev=ctd -chardev testdev,id=ctd
      or, use:
         $QEMU ... \
           -device virtio-serial-device \
           -device virtconsole,chardev=ctd -chardev testdev,id=ctd
      to bind it to virtio-serial port0.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  5. 23 Jun, 2014 4 commits
  6. 19 Jun, 2014 3 commits
  7. 16 Jun, 2014 1 commit
  8. 25 Apr, 2014 2 commits
  9. 14 Mar, 2014 1 commit
    • Markus Armbruster's avatar
      blockdev: Refuse to open encrypted image unless paused · c3adb58f
      Markus Armbruster authored
      Opening an encrypted image takes an additional step: setting the key.
      Between open and the key set, the image must not be used.
      We have some protection against accidental use in place: you can't
      unpause a guest while we're missing keys.  You can, however, hot-plug
      block devices lacking keys into a running guest just fine, or insert
      media lacking keys.  In the latter case, notifying the guest of the
      insert is delayed until the key is set, which may suffice to protect
      at least some guests in common usage.
      This patch makes the protection apply in more cases, in a rather
      heavy-handed way: it doesn't let you open encrypted images unless
      we're in a paused state.
      It doesn't extend the protection to users other than the guest (block
      jobs?).  Use of runstate_check() from block.c is disgusting.  Best I
      can do right now.
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  10. 13 Mar, 2014 1 commit
  11. 02 Mar, 2014 1 commit
  12. 26 Feb, 2014 1 commit
  13. 17 Sep, 2013 1 commit
  14. 12 Sep, 2013 1 commit
  15. 22 Aug, 2013 1 commit
  16. 08 Aug, 2013 1 commit
    • Laszlo Ersek's avatar
      dump: rebase from host-private RAMBlock offsets to guest-physical addresses · 56c4bfb3
      Laszlo Ersek authored
      RAMBlock.offset                   --> GuestPhysBlock.target_start
      RAMBlock.offset + RAMBlock.length --> GuestPhysBlock.target_end
      RAMBlock.length                   --> GuestPhysBlock.target_end -
      "GuestPhysBlock.host_addr" is only used when writing the dump contents.
      This patch enables "crash" to work with the vmcore by rebasing the vmcore
      from the left side of the following diagram to the right side:
      to ram_addr   RAMBlock                  guest-visible paddrs
                  0 +-------------------+.....+-------------------+ 0
                    |         ^         |     |        ^          |
                    |       640 KB      |     |      640 KB       |
                    |         v         |     |        v          |
        0x0000a0000 +-------------------+.....+-------------------+ 0x0000a0000
                    |         ^         |     |XXXXXXXXXXXXXXXXXXX|
                    |       384 KB      |     |XXXXXXXXXXXXXXXXXXX|
                    |         v         |     |XXXXXXXXXXXXXXXXXXX|
        0x000100000 +-------------------+.....+-------------------+ 0x000100000
                    |         ^         |     |        ^          |
                    |       3583 MB     |     |      3583 MB      |
                    |         v         |     |        v          |
        0x0e0000000 +-------------------+.....+-------------------+ 0x0e0000000
                    |         ^         |.    |XXXXXXXXXXXXXXXXXXX|
                    | above_4g_mem_size | .   |XXXX PCI hole XXXXX|
                    |         v         |  .  |XXXX          XXXXX|
           ram_size +-------------------+   . |XXXX  512 MB  XXXXX|
                                         .   .|XXXXXXXXXXXXXXXXXXX|
                                          .   +-------------------+ 0x100000000
                                           .  |         ^         |
                                            . | above_4g_mem_size |
                                             .|         v         |
                                              +-------------------+ ram_size
                                                                    + 512 MB
      Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
  17. 26 Jul, 2013 1 commit
  18. 15 Jul, 2013 1 commit
  19. 28 Jun, 2013 2 commits
  20. 11 Jun, 2013 1 commit
    • Andreas Färber's avatar
      dump: Drop qmp_dump_guest_memory() stub and build for all targets · 2a78636b
      Andreas Färber authored
      qmp_dump_guest_memory() calls dump_init() and returns an Error when
      cpu_get_dump_info() returns an error, as done by the stub.
      So there is no need to have a stub for qmp_dump_guest_memory().
      Enable the documentation of the always-present dump-guest-memory command.
      That way we can drop CONFIG_HAVE_CORE_DUMP and leave configure
      completely out of the picture for target CPU features.
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
  21. 10 Jun, 2013 1 commit
  22. 01 May, 2013 1 commit
  23. 12 Mar, 2013 1 commit
  24. 01 Mar, 2013 1 commit
  25. 21 Feb, 2013 1 commit
    • Stefan Hajnoczi's avatar
      slirp: switch to GPollFD · 8917c3bd
      Stefan Hajnoczi authored
      Slirp uses rfds/wfds/xfds more extensively than other QEMU components.
      The rarely-used out-of-band TCP data feature is used.  That means we
      need the full table of select(2) to g_poll(3) events:
        rfds -> G_IO_IN | G_IO_HUP | G_IO_ERR
        wfds -> G_IO_OUT | G_IO_ERR
        xfds -> G_IO_PRI
      I came up with this table by looking at Linux fs/select.c which maps
      select(2) to poll(2) internally.
      Another detail to watch out for are the global variables that reference
      rfds/wfds/xfds during slirp_select_poll().  sofcantrcvmore() and
      sofcantsendmore() use these globals to clear fd_set bits.  When
      sofcantrcvmore() is called, the wfds bit is cleared so that the write
      handler will no longer be run for this iteration of the event loop.
      This actually seems buggy to me since TCP connections can be half-closed
      and we'd still want to handle data in half-duplex fashion.  I think the
      real intention is to avoid running the read/write handler when the
      socket has been fully closed.  This is indicated with the SS_NOFDREF
      state bit so we now check for it before invoking the TCP write handler.
      Note that UDP/ICMP code paths don't care because they are
      Note that slirp/ has a lot of tabs and sometimes mixed tabs with spaces.
      I followed the style of the surrounding code.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Message-id: 1361356113-11049-6-git-send-email-stefanha@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  26. 12 Jan, 2013 1 commit
  27. 08 Jan, 2013 3 commits
  28. 19 Dec, 2012 4 commits