1. 10 12月, 2014 6 次提交
  2. 09 12月, 2014 1 次提交
  3. 04 12月, 2014 2 次提交
  4. 01 12月, 2014 4 次提交
  5. 28 11月, 2014 2 次提交
    • D
      Fix for crash after migration in virtio-rng on bi-endian targets · db12451d
      David Gibson 提交于
      VirtIO devices now remember which endianness they're operating in in order
      to support targets which may have guests of either endianness, such as
      powerpc.  This endianness state is transferred in a subsection of the
      virtio device's information.
      
      With virtio-rng this can lead to an abort after a loadvm hitting the
      assert() in virtio_is_big_endian().  This can be reproduced by doing a
      migrate and load from file on a bi-endian target with a virtio-rng device.
      The actual guest state isn't particularly important to triggering this.
      
      The cause is that virtio_rng_load_device() calls virtio_rng_process() which
      accesses the ring and thus needs the endianness.  However,
      virtio_rng_process() is called via virtio_load() before it loads the
      subsections.  Essentially the ->load callback in VirtioDeviceClass should
      only be used for actually reading the device state from the stream, not for
      post-load re-initialization.
      
      This patch fixes the bug by moving the virtio_rng_process() after the call
      to virtio_load().  Better yet would be to convert virtio to use vmsd and
      have the virtio_rng_process() as a post_load callback, but that's a bigger
      project for another day.
      
      This is bugfix, and should be considered for the 2.2 branch.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
      Message-id: 1417067290-20715-1-git-send-email-david@gibson.dropbear.id.au
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      db12451d
    • J
      virtio-net: fix unmap leak · 771b6ed3
      Jason Wang 提交于
      virtio_net_handle_ctrl() and other functions that process control vq
      request call iov_discard_front() which will shorten the iov. This will
      lead unmapping in virtqueue_push() leaks mapping.
      
      Fixes this by keeping the original iov untouched and using a temp variable
      in those functions.
      
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Message-id: 1417082643-23907-1-git-send-email-jasowang@redhat.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      771b6ed3
  6. 27 11月, 2014 2 次提交
    • M
      hmp: fix regression of HMP device_del auto-completion · 4cae4d5a
      Marcel Apfelbaum 提交于
      The commits:
       - 6a1fa9f5 (monitor: add del completion for peripheral device)
       - 66e56b13 (qdev: add qdev_build_hotpluggable_device_list helper)
      
      cause a QEMU crash when trying to use HMP device_del auto-completion.
      It can be easily reproduced by:
          <qemu-bin> -enable-kvm  ~/images/fedora.qcow2 -monitor stdio -device virtio-net-pci,id=vnet
      
          (qemu) device_del
          /home/mapfelba/git/upstream/qemu/hw/core/qdev.c:941:qdev_build_hotpluggable_device_list: Object 0x7f6ce04e4fe0 is not an instance of type device
          Aborted (core dumped)
      
      The root cause is qdev_build_hotpluggable_device_list going recursively over
      all peripherals and their children assuming all are devices. It doesn't work
      since PCI devices have at least on child which is a memory region (bus master).
      
      Solved by observing that all devices appear as direct children of
      /machine/peripheral container. No need of going recursively
      over all the children.
      Signed-off-by: NMarcel Apfelbaum <marcel.a@redhat.com>
      Reported-by: NGal Hammer <ghammer@redhat.com>
      Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
      Message-id: 1417002601-20799-1-git-send-email-marcel.a@redhat.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      4cae4d5a
    • P
      qemu-timer: Avoid overflows when converting timeout to struct timespec · 490309fc
      Peter Maydell 提交于
      In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
      a struct timespec, we may accidentally run into overflow problems if
      the timeout is very long. This happens because the tv_sec field is a
      time_t, which is signed, so we might end up setting it to a negative
      value by mistake. This will result in what was intended to be a
      near-infinite timeout turning into an instantaneous timeout, and we'll
      busy loop. Cap the maximum timeout at INT32_MAX seconds (about 68 years)
      to avoid this problem.
      
      This specifically manifested on ARM hosts as an extreme slowdown on
      guest shutdown (when the guest reprogrammed the PL031 RTC to not
      generate alarms using a very long timeout) but could happen on other
      hosts and guests too.
      Reported-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Message-id: 1416939705-1272-1-git-send-email-peter.maydell@linaro.org
      490309fc
  7. 26 11月, 2014 6 次提交
  8. 25 11月, 2014 9 次提交
  9. 24 11月, 2014 6 次提交
    • P
      Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging · 3d4a70f8
      Peter Maydell 提交于
      Block patches for 2.2.0-rc3
      
      # gpg: Signature made Mon 24 Nov 2014 12:52:23 GMT using RSA key ID C88F2FD6
      # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
      
      * remotes/kevin/tags/for-upstream:
        Revert "qemu-img info: show nocow info"
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      3d4a70f8
    • P
      Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging · a31a7475
      Peter Maydell 提交于
      Three patches to fix ExtINT for the QEMU implementation of the local APIC.
      
      # gpg: Signature made Mon 24 Nov 2014 13:38:36 GMT using RSA key ID 78C7AE83
      # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
      # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
      # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
      # gpg:          It is not certain that the signature belongs to the owner.
      # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
      #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
      
      * remotes/bonzini/tags/for-upstream:
        apic: fix incorrect handling of ExtINT interrupts wrt processor priority
        apic: fix loss of IPI due to masked ExtINT
        apic: avoid getting out of halted state on masked PIC interrupts
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      a31a7475
    • P
      apic: fix incorrect handling of ExtINT interrupts wrt processor priority · 5224c88d
      Paolo Bonzini 提交于
      This fixes another failure with ExtINT, demonstrated by QNX.  The failure
      mode is as follows:
      - IPI sent to cpu 0 (bit set in APIC irr)
      - IPI accepted by cpu 0 (bit cleared in irr, set in isr)
      - IPI sent to cpu 0 (bit set in both irr and isr)
      - PIC interrupt sent to cpu 0
      
      The PIC interrupt causes CPU_INTERRUPT_HARD to be set, but
      apic_irq_pending observes that the highest pending APIC interrupt priority
      (the IPI) is the same as the processor priority (since the IPI is still
      being handled), so apic_get_interrupt returns a spurious interrupt rather
      than the pending PIC interrupt. The result is an endless sequence of
      spurious interrupts, since nothing will clear CPU_INTERRUPT_HARD.
      
      Instead, ExtINT interrupts should have ignored the processor priority.
      Calling apic_check_pic early in apic_get_interrupt ensures that
      apic_deliver_pic_intr is called instead of delivering the spurious
      interrupt.  apic_deliver_pic_intr then clears CPU_INTERRUPT_HARD if needed.
      Reported-by: NRichard Bilson <rbilson@qnx.com>
      Tested-by: NRichard Bilson <rbilson@qnx.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5224c88d
    • P
      apic: fix loss of IPI due to masked ExtINT · 8092cb71
      Paolo Bonzini 提交于
      This patch fixes an obscure failure of the QNX kernel on QEMU x86 SMP.
      In QNX, all hardware interrupts come via the PIC, and are delivered by
      the cpu 0 LAPIC in ExtINT mode, while IPIs are delivered by the LAPIC
      in fixed mode.
      
      This bug happens as follows:
      - cpu 0 masks a particular PIC interrupt
      - IPI sent to cpu 0 (CPU_INTERRUPT_HARD is set)
      - before the IPI is accepted, the masked interrupt line is asserted by the
      device
      
      Since the interrupt is masked, apic_deliver_pic_intr will clear
      CPU_INTERRUPT_HARD. The IPI will still be set in the APIC irr, but since
      CPU_INTERRUPT_HARD is not set the cpu will not notice. Depending on the
      scenario this can cause a system hang, i.e. if cpu 0 is expected to unmask
      the interrupt.
      
      In order to fix this, do a full check of the APIC before an EXTINT
      is acknowledged.  This can result in clearing CPU_INTERRUPT_HARD, but
      can also result in delivering the lost IPI.
      Reported-by: NRichard Bilson <rbilson@qnx.com>
      Tested-by: NRichard Bilson <rbilson@qnx.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8092cb71
    • P
      apic: avoid getting out of halted state on masked PIC interrupts · 60e68042
      Paolo Bonzini 提交于
      After the next patch, if a masked PIC interrupts causes CPU_INTERRUPT_POLL
      to be set, the CPU will spuriously get out of halted state.  While this
      is technically valid, we should avoid that.
      
      Make CPU_INTERRUPT_POLL run apic_update_irq in the right thread and then
      look at CPU_INTERRUPT_HARD.  If CPU_INTERRUPT_HARD does not get set,
      do not report the CPU as having work.
      
      Also move the handling of software-disabled APIC from apic_update_irq
      to apic_irq_pending, and always trigger CPU_INTERRUPT_POLL.  This will
      be important once we will add a case that resets CPU_INTERRUPT_HARD
      from apic_update_irq.  We want to run it even if we go through
      CPU_INTERRUPT_POLL, and even if the local APIC is software disabled.
      Reported-by: NRichard Bilson <rbilson@qnx.com>
      Tested-by: NRichard Bilson <rbilson@qnx.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      60e68042
    • K
      Revert "qemu-img info: show nocow info" · 24bf10da
      Kevin Wolf 提交于
      This reverts commit 000c4dff.
      
      The main reason for reverting this commit before the 2.2 release is that
      it adds a QAPI interface that we don't want to keep: The 'nocow' flag
      doesn't generally make sense for block nodes, but only for the raw-posix
      driver. It should therefore be part of ImageInfoSpecific rather than
      ImageInfo.
      
      The commit contains more problems, but unlike the API stability issue
      they wouldn't justify reverting it.
      
      Conflicts:
      	block/qapi.c
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      24bf10da
  10. 23 11月, 2014 2 次提交