1. 24 Nov, 2014 4 commits
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging · a31a7475
      Peter Maydell authored
      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: default avatarPeter Maydell <peter.maydell@linaro.org>
      a31a7475
    • Paolo Bonzini's avatar
      apic: fix incorrect handling of ExtINT interrupts wrt processor priority · 5224c88d
      Paolo Bonzini authored
      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: default avatarRichard Bilson <rbilson@qnx.com>
      Tested-by: default avatarRichard Bilson <rbilson@qnx.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5224c88d
    • Paolo Bonzini's avatar
      apic: fix loss of IPI due to masked ExtINT · 8092cb71
      Paolo Bonzini authored
      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: default avatarRichard Bilson <rbilson@qnx.com>
      Tested-by: default avatarRichard Bilson <rbilson@qnx.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8092cb71
    • Paolo Bonzini's avatar
      apic: avoid getting out of halted state on masked PIC interrupts · 60e68042
      Paolo Bonzini authored
      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: default avatarRichard Bilson <rbilson@qnx.com>
      Tested-by: default avatarRichard Bilson <rbilson@qnx.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      60e68042
  2. 21 Nov, 2014 8 commits
  3. 20 Nov, 2014 7 commits
  4. 18 Nov, 2014 19 commits
  5. 17 Nov, 2014 2 commits
    • Peter Maydell's avatar
      target-arm: handle address translations that start at level 3 · d6be29e3
      Peter Maydell authored
      The ARMv8 address translation system defines that a page table walk
      starts at a level which depends on the translation granule size
      and the number of bits of virtual address that need to be resolved.
      Where the translation granule is 64KB and the guest sets the
      TCR.TxSZ field to between 35 and 39, it's actually possible to
      start at level 3 (the final level). QEMU's implementation failed
      to handle this case, and so we would set level to 2 and behave
      incorrectly (including invoking the C undefined behaviour of
      shifting left by a negative number). Correct the code that
      determines the starting level to deal with the start-at-3 case,
      by replacing the if-else ladder with an expression derived from
      the ARM ARM pseudocode version.
      
      This error was detected by the Coverity scan, which spotted
      the potential shift by a negative number.
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1415890569-7454-1-git-send-email-peter.maydell@linaro.org
      d6be29e3
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging · 1aba4be9
      Peter Maydell authored
      A smattering of fixes for problems that Coverity reported.
      
      # gpg: Signature made Mon 17 Nov 2014 17:03:25 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:
        hcd-musb: fix dereference null return value
        target-cris/translate.c: fix out of bounds read
        shpc: fix error propaagation
        qemu-char: fix MISSING_COMMA
        acl: fix memory leak
        nvme: remove superfluous check
        loader: fix NEGATIVE_RETURNS
        qga: fix false negative argument passing
        mips_mipssim: fix use-after-free for filename
        l2tpv3: fix fd leak
        l2tpv3: fix possible double free
        libcacard: fix resource leak
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      1aba4be9