Skip to content
  1. Apr 13, 2016
  2. Apr 12, 2016
  3. Apr 08, 2016
  4. Apr 07, 2016
  5. Apr 06, 2016
  6. Apr 05, 2016
    • Luiz Capitulino's avatar
      kvm: x86: make lapic hrtimer pinned · 61abdbe0
      Luiz Capitulino authored
      
      
      When a vCPU runs on a nohz_full core, the hrtimer used by
      the lapic emulation code can be migrated to another core.
      When this happens, it's possible to observe milisecond
      latency when delivering timer IRQs to KVM guests.
      
      The huge latency is mainly due to the fact that
      apic_timer_fn() expects to run during a kvm exit. It
      sets KVM_REQ_PENDING_TIMER and let it be handled on kvm
      entry. However, if the timer fires on a different core,
      we have to wait until the next kvm exit for the guest
      to see KVM_REQ_PENDING_TIMER set.
      
      This problem became visible after commit 9642d18e. This
      commit changed the timer migration code to always attempt
      to migrate timers away from nohz_full cores. While it's
      discussable if this is correct/desirable (I don't think
      it is), it's clear that the lapic emulation code has
      a requirement on firing the hrtimer in the same core
      where it was started. This is achieved by making the
      hrtimer pinned.
      
      Lastly, note that KVM has code to migrate timers when a
      vCPU is scheduled to run in different core. However, this
      forced migration may fail. When this happens, we can have
      the same problem. If we want 100% correctness, we'll have
      to modify apic_timer_fn() to cause a kvm exit when it runs
      on a different core than the vCPU. Not sure if this is
      possible.
      
      Here's a reproducer for the issue being fixed:
      
       1. Set all cores but core0 to be nohz_full cores
       2. Start a guest with a single vCPU
       3. Trace apic_timer_fn() and kvm_inject_apic_timer_irqs()
      
      You'll see that apic_timer_fn() will run in core0 while
      kvm_inject_apic_timer_irqs() runs in a different core. If
      you get both on core0, try running a program that takes 100%
      of the CPU and pin it to core0 to force the vCPU out.
      
      Signed-off-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      61abdbe0
    • Christian Borntraeger's avatar
      s390/mm/kvm: fix mis-merge in gmap handling · 9c650d09
      Christian Borntraeger authored
      
      
      commit 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c") dropped
      some changes from commit a3a92c31 ("KVM: s390: fix mismatch
      between user and in-kernel guest limit") - this breaks KVM for some
      memory sizes (kvm-s390: failed to commit memory region) like
      exactly 2GB.
      
      Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9c650d09
  7. Apr 04, 2016
  8. Apr 03, 2016
  9. Apr 01, 2016
    • Russell King's avatar
      ARM: SMP enable of cache maintanence broadcast · 0fc03d4c
      Russell King authored
      
      
      Masahiro Yamada reports that we can fail to set the FW bit in the
      auxiliary control register, which enables broadcasting the cache
      maintanence operations.  This occurs because we only check that the
      SMP/nAMP bit is set, rather than checking whether all the bits we
      want to be set are set.
      
      Rearrange the code to ensure that all desired bits are set, and only
      update the register if we discover some required bits are not set.
      
      Tested-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0fc03d4c
    • Nadav Amit's avatar
      mm/rmap: batched invalidations should use existing api · 858eaaa7
      Nadav Amit authored
      
      
      The recently introduced batched invalidations mechanism uses its own
      mechanism for shootdown.  However, it does wrong accounting of
      interrupts (e.g., inc_irq_stat is called for local invalidations),
      trace-points (e.g., TLB_REMOTE_SHOOTDOWN for local invalidations) and
      may break some platforms as it bypasses the invalidation mechanisms of
      Xen and SGI UV.
      
      This patch reuses the existing TLB flushing mechnaisms instead.  We use
      NULL as mm to indicate a global invalidation is required.
      
      Fixes 72b252ae ("mm: send one IPI per CPU to TLB flush all entries after unmapping pages")
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      858eaaa7
    • Nadav Amit's avatar
      x86/mm: TLB_REMOTE_SEND_IPI should count pages · 18c98243
      Nadav Amit authored
      
      
      TLB_REMOTE_SEND_IPI was recently introduced, but it counts bytes instead
      of pages.  In addition, it does not report correctly the case in which
      flush_tlb_page flushes a page.  Fix it to be consistent with other TLB
      counters.
      
      Fixes: 5b74283a ("x86, mm: trace when an IPI is about to be sent")
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      18c98243
Loading