1. 19 Sep, 2014 7 commits
    • Christoffer Dall's avatar
      arm/arm64: KVM: vgic: Clarify and correct vgic documentation · 7e362919
      Christoffer Dall authored
      The VGIC virtual distributor implementation documentation was written a
      very long time ago, before the true nature of the beast had been
      partially absorbed into my bloodstream.  Clarify the docs.
      
      Plus, it fixes an actual bug.  ICFRn, pfff.
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      7e362919
    • Christoffer Dall's avatar
      arm/arm64: KVM: vgic: Fix SGI writes to GICD_I{CS}PENDR0 · 9da48b55
      Christoffer Dall authored
      Writes to GICD_ISPENDR0 and GICD_ICPENDR0 ignore all settings of the
      pending state for SGIs.  Make sure the implementation handles this
      correctly.
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      9da48b55
    • Christoffer Dall's avatar
      arm/arm64: KVM: vgic: Improve handling of GICD_I{CS}PENDRn · faa1b46c
      Christoffer Dall authored
      Writes to GICD_ISPENDRn and GICD_ICPENDRn are currently not handled
      correctly for level-triggered interrupts.  The spec states that for
      level-triggered interrupts, writes to the GICD_ISPENDRn activate the
      output of a flip-flop which is in turn or'ed with the actual input
      interrupt signal.  Correspondingly, writes to GICD_ICPENDRn simply
      deactivates the output of that flip-flop, but does not (of course) affect
      the external input signal.  Reads from GICC_IAR will also deactivate the
      flip-flop output.
      
      This requires us to track the state of the level-input separately from
      the state in the flip-flop.  We therefore introduce two new variables on
      the distributor struct to track these two states.  Astute readers may
      notice that this is introducing more state than required (because an OR
      of the two states gives you the pending state), but the remaining vgic
      code uses the pending bitmap for optimized operations to figure out, at
      the end of the day, if an interrupt is pending or not on the distributor
      side.  Refactoring the code to consider the two state variables all the
      places where we currently access the precomputed pending value, did not
      look pretty.
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      faa1b46c
    • Christoffer Dall's avatar
      arm/arm64: KVM: vgic: Clear queued flags on unqueue · cced50c9
      Christoffer Dall authored
      If we unqueue a level-triggered interrupt completely, and the LR does
      not stick around in the active state (and will therefore no longer
      generate a maintenance interrupt), then we should clear the queued flag
      so that the vgic can actually queue this level-triggered interrupt at a
      later time and deal with its pending state then.
      
      Note: This should actually be properly fixed to handle the active state
      on the distributor.
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      cced50c9
    • Christoffer Dall's avatar
      arm/arm64: KVM: Rename irq_active to irq_queued · dbf20f9d
      Christoffer Dall authored
      We have a special bitmap on the distributor struct to keep track of when
      level-triggered interrupts are queued on the list registers.  This was
      named irq_active, which is confusing, because the active state of an
      interrupt as per the GIC spec is a different thing, not specifically
      related to edge-triggered/level-triggered configurations but rather
      indicates an interrupt which has been ack'ed but not yet eoi'ed.
      
      Rename the bitmap and the corresponding accessor functions to irq_queued
      to clarify what this is actually used for.
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      dbf20f9d
    • Christoffer Dall's avatar
      arm/arm64: KVM: Rename irq_state to irq_pending · 227844f5
      Christoffer Dall authored
      The irq_state field on the distributor struct is ambiguous in its
      meaning; the comment says it's the level of the input put, but that
      doesn't make much sense for edge-triggered interrupts.  The code
      actually uses this state variable to check if the interrupt is in the
      pending state on the distributor so clarify the comment and rename the
      actual variable and accessor methods.
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      227844f5
    • Christoffer Dall's avatar
      Merge remote-tracking branch 'kvm/next' into queue · a875dafc
      Christoffer Dall authored
      Conflicts:
      	arch/arm64/include/asm/kvm_host.h
      	virt/kvm/arm/vgic.c
      a875dafc
  2. 17 Sep, 2014 6 commits
  3. 16 Sep, 2014 2 commits
    • Zhang Haoyu's avatar
      kvm: ioapic: conditionally delay irq delivery duringeoi broadcast · 184564ef
      Zhang Haoyu authored
      Currently, we call ioapic_service() immediately when we find the irq is still
      active during eoi broadcast. But for real hardware, there's some delay between
      the EOI writing and irq delivery.  If we do not emulate this behavior, and
      re-inject the interrupt immediately after the guest sends an EOI and re-enables
      interrupts, a guest might spend all its time in the ISR if it has a broken
      handler for a level-triggered interrupt.
      
      Such livelock actually happens with Windows guests when resuming from
      hibernation.
      
      As there's no way to recognize the broken handle from new raised ones, this patch
      delays an interrupt if 10.000 consecutive EOIs found that the interrupt was
      still high.  The guest can then make a little forward progress, until a proper
      IRQ handler is set or until some detection routine in the guest (such as
      Linux's note_interrupt()) recognizes the situation.
      
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarZhang Haoyu <zhanghy@sangfor.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      184564ef
    • Guo Hui Liu's avatar
      KVM: x86: Use kvm_make_request when applicable · 105b21bb
      Guo Hui Liu authored
      This patch replace the set_bit method by kvm_make_request
      to make code more readable and consistent.
      Signed-off-by: default avatarGuo Hui Liu <liuguohui@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      105b21bb
  4. 11 Sep, 2014 5 commits
  5. 10 Sep, 2014 9 commits
  6. 05 Sep, 2014 5 commits
  7. 03 Sep, 2014 6 commits
    • Paolo Bonzini's avatar
      KVM: nSVM: propagate the NPF EXITINFO to the guest · 5e352519
      Paolo Bonzini authored
      This is similar to what the EPT code does with the exit qualification.
      This allows the guest to see a valid value for bits 33:32.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5e352519
    • Paolo Bonzini's avatar
      KVM: x86: reserve bit 8 of non-leaf PDPEs and PML4Es in 64-bit mode on AMD · a0c0feb5
      Paolo Bonzini authored
      Bit 8 would be the "global" bit, which does not quite make sense for non-leaf
      page table entries.  Intel ignores it; AMD ignores it in PDEs, but reserves it
      in PDPEs and PML4Es.  The SVM test is relying on this behavior, so enforce it.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a0c0feb5
    • Tiejun Chen's avatar
      KVM: mmio: cleanup kvm_set_mmio_spte_mask · d1431483
      Tiejun Chen authored
      Just reuse rsvd_bits() inside kvm_set_mmio_spte_mask()
      for slightly better code.
      Signed-off-by: default avatarTiejun Chen <tiejun.chen@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d1431483
    • David Matlack's avatar
      kvm: x86: fix stale mmio cache bug · 56f17dd3
      David Matlack authored
      The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
      up to userspace:
      
      (1) Guest accesses gpa X without a memory slot. The gfn is cached in
      struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
      the SPTE write-execute-noread so that future accesses cause
      EPT_MISCONFIGs.
      
      (2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION
      covering the page just accessed.
      
      (3) Guest attempts to read or write to gpa X again. On Intel, this
      generates an EPT_MISCONFIG. The memory slot generation number that
      was incremented in (2) would normally take care of this but we fast
      path mmio faults through quickly_check_mmio_pf(), which only checks
      the per-vcpu mmio cache. Since we hit the cache, KVM passes a
      KVM_EXIT_MMIO up to userspace.
      
      This patch fixes the issue by using the memslot generation number
      to validate the mmio cache.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      [xiaoguangrong: adjust the code to make it simpler for stable-tree fix.]
      Signed-off-by: default avatarXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Reviewed-by: default avatarDavid Matlack <dmatlack@google.com>
      Reviewed-by: default avatarXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Tested-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      56f17dd3
    • David Matlack's avatar
      kvm: fix potentially corrupt mmio cache · ee3d1570
      David Matlack authored
      vcpu exits and memslot mutations can run concurrently as long as the
      vcpu does not aquire the slots mutex. Thus it is theoretically possible
      for memslots to change underneath a vcpu that is handling an exit.
      
      If we increment the memslot generation number again after
      synchronize_srcu_expedited(), vcpus can safely cache memslot generation
      without maintaining a single rcu_dereference through an entire vm exit.
      And much of the x86/kvm code does not maintain a single rcu_dereference
      of the current memslots during each exit.
      
      We can prevent the following case:
      
         vcpu (CPU 0)                             | thread (CPU 1)
      --------------------------------------------+--------------------------
      1  vm exit                                  |
      2  srcu_read_unlock(&kvm->srcu)             |
      3  decide to cache something based on       |
           old memslots                           |
      4                                           | change memslots
                                                  | (increments generation)
      5                                           | synchronize_srcu(&kvm->srcu);
      6  retrieve generation # from new memslots  |
      7  tag cache with new memslot generation    |
      8  srcu_read_unlock(&kvm->srcu)             |
      ...                                         |
         <action based on cache occurs even       |
          though the caching decision was based   |
          on the old memslots>                    |
      ...                                         |
         <action *continues* to occur until next  |
          memslot generation change, which may    |
          be never>                               |
                                                  |
      
      By incrementing the generation after synchronizing with kvm->srcu readers,
      we ensure that the generation retrieved in (6) will become invalid soon
      after (8).
      
      Keeping the existing increment is not strictly necessary, but we
      do keep it and just move it for consistency from update_memslots to
      install_new_memslots.  It invalidates old cached MMIOs immediately,
      instead of having to wait for the end of synchronize_srcu_expedited,
      which makes the code more clearly correct in case CPU 1 is preempted
      right after synchronize_srcu() returns.
      
      To avoid halving the generation space in SPTEs, always presume that the
      low bit of the generation is zero when reconstructing a generation number
      out of an SPTE.  This effectively disables MMIO caching in SPTEs during
      the call to synchronize_srcu_expedited.  Using the low bit this way is
      somewhat like a seqcount---where the protected thing is a cache, and
      instead of retrying we can simply punt if we observe the low bit to be 1.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Reviewed-by: default avatarXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Reviewed-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ee3d1570
    • Paolo Bonzini's avatar
      KVM: do not bias the generation number in kvm_current_mmio_generation · 00f034a1
      Paolo Bonzini authored
      The next patch will give a meaning (a la seqcount) to the low bit of the
      generation number.  Ensure that it matches between kvm->memslots->generation
      and kvm_current_mmio_generation().
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarDavid Matlack <dmatlack@google.com>
      Reviewed-by: default avatarXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      00f034a1