Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: master
Commits on Apr 27, 2015
  1. @pm215

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-gtk-20150427-1…

    pm215 authored
    …' into staging
    
    gtk: support text consoles without vte, bugfixes.
    
    # gpg: Signature made Mon Apr 27 14:34:15 2015 BST using RSA key ID D3E87138
    # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
    # gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
    # gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
    
    * remotes/kraxel/tags/pull-gtk-20150427-1:
      gtk: Avoid accel key leakage into guest on console switch
      gtk: Fix VTE focus grabbing
      console/gtk: add qemu_console_get_label
      gtk: bind to text terminal consoles too
      gtk: handle switch_surface(NULL) properly
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. @pm215

    Merge remote-tracking branch 'remotes/qmp-unstable/tags/for-upstream'…

    pm215 authored
    … into staging
    
    Four little fixes
    
    # gpg: Signature made Fri Apr 24 19:56:51 2015 BST using RSA key ID E24ED5A7
    # gpg: Good signature from "Luiz Capitulino <lcapitulino@gmail.com>"
    
    * remotes/qmp-unstable/tags/for-upstream:
      qmp: Give saner messages related to qmp_capabilities misuse
      qmp-commands: fix incorrect uses of ":O" specifier
      qapi: Drop dead genlist parameter
      balloon: improve error msg when adding second device
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  3. @jan-kiszka @kraxel

    gtk: Avoid accel key leakage into guest on console switch

    jan-kiszka authored kraxel committed
    GTK2 sends the accel key to the guest when switching to the graphic
    console via that shortcut. Resolve this by ignoring any keys until the
    next key-release event. However, do not ignore keys when switching via
    the menu or when on GTK3.
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
  4. @jan-kiszka @kraxel

    gtk: Fix VTE focus grabbing

    jan-kiszka authored kraxel committed
    At least on GTK2, the VTE terminal has to be specified as target of
    gtk_widget_grab_focus. Otherwise, switching from one VTE terminal to
    another causes the focus to get lost.
    
    CC: John Snow <jsnow@redhat.com>
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    
    [ kraxel: fixed build with CONFIG_VTE=n ]
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commits on Apr 25, 2015
  1. @pm215

    Open 2.4 development tree

    pm215 authored
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Apr 24, 2015
  1. qmp: Give saner messages related to qmp_capabilities misuse

    Eric Blake authored Luiz Capitulino committed
    Pretending that QMP doesn't understand a command merely because
    we are not in the right mode doesn't help first-time users figure
    out what to do to correct things.  Although the documentation for
    QMP calls out capabilities negotiation, we should also make it
    clear in our error messages what we were expecting.  With this
    patch, I now get the following transcript:
    
    $ ./x86_64-softmmu/qemu-system-x86_64 -qmp stdio -nodefaults
    {"QMP": {"version": {"qemu": {"micro": 93, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}}
    {"execute":"huh"}
    {"error": {"class": "CommandNotFound", "desc": "The command huh has not been found"}}
    {"execute":"quit"}
    {"error": {"class": "CommandNotFound", "desc": "Expecting capabilities negotiation with 'qmp_capabilities' before command 'quit'"}}
    {"execute":"qmp_capabilities"}
    {"return": {}}
    {"execute":"qmp_capabilities"}
    {"error": {"class": "CommandNotFound", "desc": "Capabilities negotiation is already complete, command 'qmp_capabilities' ignored"}}
    {"execute":"quit"}
    {"return": {}}
    {"timestamp": {"seconds": 1429110729, "microseconds": 181935}, "event": "SHUTDOWN"}
    
    Signed-off-by: Eric Blake <eblake@redhat.com>
    Tested-By: Kashyap Chamarthy <kchamart@redhat.com>
    Reviewed-by: Paulo Vital <paulo.vital@profitbricks.com>
    Reviewed-by: John Snow <jsnow@redhat.com>
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
  2. @bonzini

    qmp-commands: fix incorrect uses of ":O" specifier

    bonzini authored Luiz Capitulino committed
    As far as the QMP parser is concerned, neither the 'O' nor the 'q' format specifiers
    put any constraint on the command.  However, there are two differences:
    
    1) from a documentation point of view 'O' says that this command takes
    a dictionary.  The dictionary will be converted to QemuOpts in the
    handler to match the corresponding HMP command.
    
    2) 'O' sets QMP_ACCEPT_UNKNOWNS, resulting in the command accepting invalid
    extra arguments.  For example the following is accepted:
    
       { "execute": "send-key",
            "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" },
                                     { "type": "qcode", "data": "alt" },
                                     { "type": "qcode", "data": "delete" } ], "foo": "bar" } }
    
    Neither send-key nor migrate-set-capabilities take a QemuOpts-like
    dictionary; they take an array of dictionaries.  And neither command
    really wants to have extra unknown arguments.  Thus, the right
    specifier to use in this case is 'q'; with this patch the above
    command fails with
    
       {"error": {"class": "GenericError", "desc": "Invalid parameter 'foo'"}}
    
    as intended.
    
    Reported-by: Alberto Garcia <berto@igalia.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Alberto Garcia <berto@igalia.com>
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
  3. qapi: Drop dead genlist parameter

    Eric Blake authored Luiz Capitulino committed
    Defaulting a parameter to True, then having all callers omit or
    pass an explicit True for that parameter, is pointless. Looks
    like it has been dead since introduction in commit 06d64c6, more
    than 4 years ago.
    
    Signed-off-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
  4. balloon: improve error msg when adding second device

    Luiz Capitulino authored
    A VM supports only one balloon device, but due to several changes
    in infrastructure the error message got messed up when trying
    to add a second device. Fix it.
    
    Before this fix
    
    Command-line:
    
    qemu-qmp: -device virtio-balloon-pci,id=balloon0: Another balloon device already registered
    qemu-qmp: -device virtio-balloon-pci,id=balloon0: Adding balloon handler failed
    qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized
    
    HMP:
    
    Another balloon device already registered
    Adding balloon handler failed
    Device 'virtio-balloon-pci' could not be initialized
    
    QMP:
    
    { "execute": "device_add", "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } }
    {
    	"error": {
    		"class": "GenericError",
    		"desc": "Adding balloon handler failed"
    	}
    }
    
    After this fix
    
    Command-line:
    
    qemu-qmp: -device virtio-balloon-pci,id=balloon0: Only one balloon device is supported
    qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized
    
    HMP:
    
    (qemu) device_add virtio-balloon-pci,id=balloon0
    Only one balloon device is supported
    Device 'virtio-balloon-pci' could not be initialized
    (qemu)
    
    QMP:
    
    { "execute": "device_add",
              "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } }
    {
        "error": {
            "class": "GenericError",
            "desc": "Only one balloon device is supported"
        }
    }
    
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
  5. @pm215

    Update version for v2.3.0 release

    pm215 authored
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Apr 22, 2015
  1. @kraxel

    console/gtk: add qemu_console_get_label

    kraxel authored
    Add a new function to get a nice label for a given QemuConsole.
    Drop the labeling code in gtk.c and use the new function instead.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
  2. @kraxel

    gtk: bind to text terminal consoles too

    kraxel authored
    This way gtk has text terminal consoles even when building without vte.
    Most notably you'll get a monitor tab on windows now.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
  3. @kraxel

    gtk: handle switch_surface(NULL) properly

    kraxel authored
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commits on Apr 20, 2015
  1. @pm215

    Update version for v2.3.0-rc4 release

    pm215 authored
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. @mstsirkin @pm215

    vhost: fix log base address

    mstsirkin authored pm215 committed
    VHOST_SET_LOG_BASE got an incorrect address, causing
    migration errors and potentially even memory corruption.
    
    Reported-by: Wen Congyang <wency@cn.fujitsu.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Message-id: 1429283565-32265-1-git-send-email-mst@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Apr 17, 2015
  1. @bertogg @pm215

    hmp: fix crash in 'info block -n -v'

    bertogg authored pm215 committed
    The image field in BlockDeviceInfo should never be null, however
    bdrv_block_device_info() is not filling it in.
    
    This makes the 'info block -n -v' command crash QEMU.
    
    The proper solution is probably to move the relevant code from
    bdrv_query_info() to bdrv_block_device_info(), but since we're too
    close to the release for that this simpler workaround solves the
    crash.
    
    Signed-off-by: Alberto Garcia <berto@igalia.com>
    Message-id: 1429274688-8115-1-git-send-email-berto@igalia.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. @pm215

    Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150417-2' in…

    pm215 authored
    …to staging
    
    MIPS patches 2015-04-17
    
    Changes:
    * fix broken fulong2e
    
    # gpg: Signature made Fri Apr 17 12:14:37 2015 BST using RSA key ID 0B29DA6B
    # gpg: Can't check signature: public key not found
    
    * remotes/lalrae/tags/mips-20150417-2:
      mips: fix broken fulong2e machine
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  3. @pm215

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-fwcfg-20150414…

    pm215 authored
    …-1' into staging
    
    fw_cfg: add documentation file (docs/specs/fw_cfg.txt)
    
    # gpg: Signature made Tue Apr 14 12:22:20 2015 BST using RSA key ID D3E87138
    # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
    # gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
    # gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
    
    * remotes/kraxel/tags/pull-fwcfg-20150414-1:
      fw_cfg: add documentation file (docs/specs/fw_cfg.txt)
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  4. @bonzini @lalrae

    mips: fix broken fulong2e machine

    bonzini authored lalrae committed
    After commit 5312bd8 the bonito_readl() and bonito_writel() have been
    accessing incorrect addresses. Consequently QEMU is crashing when trying
    to boot Linux kernel on fulong2e machine.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
  5. @mcayland @pm215

    target-ppc: don't invalidate msr MSR_HVB bit in cpu_post_load

    mcayland authored pm215 committed
    The invalidation code introduced in commit 2360b works by inverting most bits
    of env->msr to ensure that hreg_store_msr() will forcibly update the CPU env
    state to reflect the new msr value post-migration. Unfortunately
    hreg_store_msr() is called with alter_hv set to 0 which preserves the MSR_HVB
    state from the CPU env which is now the opposite value to what it should be.
    
    Ensure that we don't invalidate the msr MSR_HVB bit during cpu_post_load so
    that the correct value is restored. This fixes suspend/resume for PPC64.
    
    Reported-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
    Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
    Reviewed-by: Alexander Graf <agraf@suse.de>
    Message-id: 1429255009-12751-1-git-send-email-mark.cave-ayland@ilande.co.uk
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Apr 14, 2015
  1. @kraxel

    fw_cfg: add documentation file (docs/specs/fw_cfg.txt)

    Gabriel L. Somlo authored kraxel committed
    This document covers the guest-side hardware interface, as
    well as the host-side programming API of QEMU's firmware
    configuration (fw_cfg) device.
    
    Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
    Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commits on Apr 13, 2015
  1. @pm215

    Update version for v2.3.0-rc3 release

    pm215 authored
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. @pm215

    Revert seccomp tests that allow it to be used on non-x86 architectures

    pm215 authored
    Unfortunately it turns out that libseccomp 2.2 still does not work
    correctly on non-x86 architectures; return to the previous configure
    setup of insisting on libseccomp 2.1 or better and i386/x86_64 and
    disabling seccomp support in all other situations.
    
    This reverts the two commits:
     * "seccomp: libseccomp version varying according to arch"
       (commit 896848f)
     * "seccomp: update libseccomp version and remove arch restriction"
       (commit 8e27fc2)
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Message-id: 1428670681-23032-1-git-send-email-peter.maydell@linaro.org
  3. @huth @pm215

    pci: Fix crash with illegal "-net nic, model=xxx" option

    huth authored pm215 committed
    Current QEMU crashes when specifying an illegal model with the
    "-net nic,model=xxx" option, e.g.:
    
     $ qemu-system-x86_64 -net nic,model=n/a
     qemu-system-x86_64: Unsupported NIC model: n/a
    
     Program received signal SIGSEGV, Segmentation fault.
    
    The gdb backtrace looks like this:
    
    0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152
    152	    return err->msg;
    (gdb) bt
     0  0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152
     1  0x0000555555965ffd in error_report_err (err=0x0) at util/error.c:157
     2  0x0000555555809c90 in pci_nic_init_nofail (nd=0x555555e49860 <nd_table>, rootbus=0x5555564409b0,
        default_model=0x55555598c37b "e1000", default_devaddr=0x0) at hw/pci/pci.c:1663
     3  0x0000555555691e42 in pc_nic_init (isa_bus=0x555556f71900, pci_bus=0x5555564409b0)
        at hw/i386/pc.c:1506
     4  0x000055555569396b in pc_init1 (machine=0x5555562abbf0, pci_enabled=1, kvmclock_enabled=1)
        at hw/i386/pc_piix.c:248
     5  0x0000555555693d27 in pc_init_pci (machine=0x5555562abbf0) at hw/i386/pc_piix.c:310
     6  0x000055555572ddf5 in main (argc=3, argv=0x7fffffffe018, envp=0x7fffffffe038) at vl.c:4226
    
    The problem is that pci_nic_init_nofail() does not check whether the err
    parameter from pci_nic_init has been set up and thus passes a NULL pointer
    to error_report_err(). Fix it by correctly checking the err parameter.
    
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  4. @pm215

    stm32f205: Fix SoC type name

    authored pm215 committed
    The type name for the SoC device, unlike those of its sub-devices,
    did not follow the QOM naming conventions. While the usage is internal
    only, this is exposed through QMP and HMP, so fix it before release.
    
    Cc: Alistair Francis <alistair.francis@xilinx.com>
    Signed-off-by: Andreas Färber <afaerber@suse.de>
    Reviewed-by: Alistair Francis <alistair@alistair23.me>
    Message-id: 1428676676-23056-1-git-send-email-afaerber@suse.de
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Apr 11, 2015
  1. @dirkmueller

    cris: memory: Replace memory_region_init_ram with memory_region_alloc…

    dirkmueller authored Edgar E. Iglesias committed
    …ate_system_memory
    
    Commit 0b183fc:"memory: move mem_path handling to
    memory_region_allocate_system_memory" split memory_region_init_ram and
    memory_region_init_ram_from_file. Also it moved mem-path handling a step
    up from memory_region_init_ram to memory_region_allocate_system_memory.
    
    Therefore for any board that uses memory_region_init_ram directly,
    -mem-path is not supported.
    
    Fix this by replacing memory_region_init_ram with
    memory_region_allocate_system_memory.
    
    Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
    Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
    Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
    Signed-off-by: Dirk Mueller <dmueller@suse.com>
    Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Commits on Apr 10, 2015
  1. @dirkmueller @pm215

    alpha: memory: Replace memory_region_init_ram with memory_region_allo…

    dirkmueller authored pm215 committed
    …cate_system_memory
    
    Commit 0b183fc:"memory: move mem_path handling to
    memory_region_allocate_system_memory" split memory_region_init_ram and
    memory_region_init_ram_from_file. Also it moved mem-path handling a step
    up from memory_region_init_ram to memory_region_allocate_system_memory.
    
    Therefore for any board that uses memory_region_init_ram directly,
    -mem-path is not supported.
    
    Fix this by replacing memory_region_init_ram with
    memory_region_allocate_system_memory.
    
    Cc: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Dirk Mueller <dmueller@suse.com>
    Acked-by: Richard Henderson <rth@twiddle.net>
    Message-id: CAL5wTH64_ykF17cw2T1Axq8P3vCWm=6WbUJ3qJrLF-u+-MmzUw@mail.gmail.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. @dirkmueller @pm215

    lm32: memory: Replace memory_region_init_ram with memory_region_alloc…

    dirkmueller authored pm215 committed
    …ate_system_memory
    
    Commit 0b183fc:"memory: move mem_path handling to
    memory_region_allocate_system_memory" split memory_region_init_ram and
    memory_region_init_ram_from_file. Also it moved mem-path handling a step
    up from memory_region_init_ram to memory_region_allocate_system_memory.
    
    Therefore for any board that uses memory_region_init_ram directly,
    -mem-path is not supported.
    
    Fix this by replacing memory_region_init_ram with
    memory_region_allocate_system_memory.
    
    Cc: Michael Walle <michael@walle.cc>
    Signed-off-by: Dirk Mueller <dmueller@suse.com>
    Acked-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Apr 9, 2015
  1. @jbeulich @pm215

    xen: limit guest control of PCI command register

    jbeulich authored pm215 committed
    Otherwise the guest can abuse that control to cause e.g. PCIe
    Unsupported Request responses (by disabling memory and/or I/O decoding
    and subsequently causing [CPU side] accesses to the respective address
    ranges), which (depending on system configuration) may be fatal to the
    host.
    
    This is CVE-2015-2756 / XSA-126.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Message-id: alpine.DEB.2.02.1503311510300.7690@kaball.uk.xensource.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. @pm215

    configure: disable Archipelago by default and warn about libxseg GPLv…

    Stefan Hajnoczi authored pm215 committed
    …3 license
    
    libxseg has changed license to GPLv3.  QEMU includes GPL "v2 only" code
    which is not compatible with GPLv3.  This means the resulting binaries
    may not be redistributable!
    
    Disable Archipelago (libxseg) by default to prevent accidental license
    violations.  Also warn if linking against libxseg is enabled to remind
    the user.
    
    Note that this commit does not constitute any advice about software
    licensing.  If you have doubts you should consult a lawyer.
    
    Cc: Chrysostomos Nanakos <cnanakos@grnet.gr>
    Suggested-by: Kevin Wolf <kwolf@redhat.com>
    Reported-by: Andreas Färber <afaerber@suse.de>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Reviewed-by: Andreas Färber <afaerber@suse.de>
    Message-id: 1428587538-8765-1-git-send-email-stefanha@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  3. @pm215

    Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-reques…

    pm215 authored
    …t' into staging
    
    # gpg: Signature made Thu Apr  9 10:55:11 2015 BST using RSA key ID 81AB73C8
    # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
    # gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
    
    * remotes/stefanha/tags/block-pull-request:
      block/iscsi: handle zero events from iscsi_which_events
      aio: strengthen memory barriers for bottom half scheduling
      virtio-blk: correctly dirty guest memory
      qcow2: Fix header update with overridden backing file
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  4. @pm215

    tcg/tcg-op.c: Fix ld/st of 64 bit values on 32-bit bigendian hosts

    pm215 authored
    Commit 951c630 out-of-lined the 32-bit-host versions of
    tcg_gen_{ld,st}_i64, but in the process it inadvertently changed
    an #ifdef HOST_WORDS_BIGENDIAN to #ifdef TCG_TARGET_WORDS_BIGENDIAN.
    Since the latter doesn't get defined anywhere this meant we always
    took the "LE host" codepath, and stored the two halves of the value
    in the wrong order on BE hosts. This typically breaks any 64-bit
    guest on a 32-bit BE host completely, and will have possibly more
    subtle effects even for 32-bit guests.
    
    Switch the ifdef back to HOST_WORDS_BIGENDIAN.
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Richard Henderson <rth@twiddle.net>
    Tested-by: Andreas Färber <afaerber@suse.de>
    Message-id: 1428523029-13620-1-git-send-email-peter.maydell@linaro.org
  5. @plieven

    block/iscsi: handle zero events from iscsi_which_events

    plieven authored Stefan Hajnoczi committed
    newer libiscsi versions may return zero events from iscsi_which_events.
    
    In this case iscsi_service will return immediately without any progress.
    To avoid busy waiting for iscsi_which_events to change we deregister all
    read and write handlers in this case and schedule a timer to periodically
    check iscsi_which_events for changed events.
    
    Next libiscsi version will introduce async reconnects and zero events
    are returned while libiscsi is waiting for a reconnect retry.
    
    Signed-off-by: Peter Lieven <pl@kamp.de>
    Message-id: 1428437295-29577-1-git-send-email-pl@kamp.de
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
  6. @bonzini

    aio: strengthen memory barriers for bottom half scheduling

    bonzini authored Stefan Hajnoczi committed
    There are two problems with memory barriers in async.c.  The fix is
    to use atomic_xchg in order to achieve sequential consistency between
    the scheduling of a bottom half and the corresponding execution.
    
    First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
    not execute a memory barrier to order any writes needed by the callback
    before the read of bh->scheduled.  If the other side sees req->state as
    THREAD_ACTIVE, the callback is not invoked and you get deadlock.
    
    Second, the memory barrier in aio_bh_poll is too weak.  Without this
    patch, it is possible that bh->scheduled = 0 is not "published" until
    after the callback has returned.  Another thread wants to schedule the
    bottom half, but it sees bh->scheduled = 1 and does nothing.  This causes
    a lost wakeup.  The memory barrier should have been changed to smp_mb()
    in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition,
    2014-06-03) together with qemu_bh_schedule()'s.  Guess who reviewed
    that patch?
    
    Both of these involve a store and a load, so they are reproducible on
    x86_64 as well.  It is however much easier on aarch64, where the
    libguestfs test suite triggers the bug fairly easily.  Even there the
    failure can go away or appear depending on compiler optimization level,
    tracing options, or even kernel debugging options.
    
    Paul Leveille however reported how to trigger the problem within 15
    minutes on x86_64 as well.  His (untested) recipe, reproduced here
    for reference, is the following:
    
       1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.
    
       2) Use “cache=directsync” rather than the default of
       “cache=none” to make it happen easier.
    
       3) Use a server with a write-back RAID controller to allow for rapid
       IO rates.
    
       4) Run a random-access load that (mostly) writes chunks to various
       files on the virtual block device.
    
          a. I use ‘diskload.exe c:25’, a Microsoft HCT load
             generator, on Windows VMs.
    
          b. Iometer can probably be configured to generate a similar load.
    
       5) Run multiple VMs in parallel, against the same storage device,
       to shake the failure out sooner.
    
       6) IvyBridge and Haswell processors for certain; not sure about others.
    
    A similar patch survived over 12 hours of testing, where an unpatched
    QEMU would fail within 15 minutes.
    
    This bug is, most likely, also the cause of failures in the libguestfs
    testsuite on AArch64.
    
    Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
    Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
    Paul for providing test input and a prototype patch.
    
    Reported-by: Laszlo Ersek <lersek@redhat.com>
    Reported-by: Paul Leveille <Paul.Leveille@stratus.com>
    Reported-by: John Snow <jsnow@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com
    Suggested-by: Paul Leveille <Paul.Leveille@stratus.com>
    Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Commits on Apr 8, 2015
  1. @dirkmueller @pm215

    arm: memory: Replace memory_region_init_ram with memory_region_alloca…

    dirkmueller authored pm215 committed
    …te_system_memory
    
    Commit 0b183fc:"memory: move mem_path handling to
    memory_region_allocate_system_memory" split memory_region_init_ram and
    memory_region_init_ram_from_file. Also it moved mem-path handling a step
    up from memory_region_init_ram to memory_region_allocate_system_memory.
    
    Therefore for any board that uses memory_region_init_ram directly,
    -mem-path is not supported.
    
    Fix this by replacing memory_region_init_ram with
    memory_region_allocate_system_memory.
    
    Signed-off-by: Dirk Mueller <dmueller@suse.com>
    Message-id: CAL5wTH4UHYKpJF=dLJfFzxpufjY189chnCow47-ySuLf8GLbug@mail.gmail.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Something went wrong with that request. Please try again.