1. 04 7月, 2016 5 次提交
  2. 29 6月, 2016 4 次提交
  3. 20 5月, 2016 4 次提交
    • C
      KVM: arm/arm64: vgic-new: Synchronize changes to active state · 35a2d585
      Christoffer Dall 提交于
      When modifying the active state of an interrupt via the MMIO interface,
      we should ensure that the write has the intended effect.
      
      If a guest sets an interrupt to active, but that interrupt is already
      flushed into a list register on a running VCPU, then that VCPU will
      write the active state back into the struct vgic_irq upon returning from
      the guest and syncing its state.  This is a non-benign race, because the
      guest can observe that an interrupt is not active, and it can have a
      reasonable expectations that other VCPUs will not ack any IRQs, and then
      set the state to active, and expect it to stay that way.  Currently we
      are not honoring this case.
      
      Thefore, change both the SACTIVE and CACTIVE mmio handlers to stop the
      world, change the irq state, potentially queue the irq if we're setting
      it to active, and then continue.
      
      We take this chance to slightly optimize these functions by not stopping
      the world when touching private interrupts where there is inherently no
      possible race.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      35a2d585
    • C
      KVM: arm/arm64: Provide functionality to pause and resume a guest · b13216cf
      Christoffer Dall 提交于
      For some rare corner cases in our VGIC emulation later we have to stop
      the guest to make sure the VGIC state is consistent.
      Provide the necessary framework to pause and resume a guest.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
      b13216cf
    • C
      KVM: arm/arm64: Export mmio_read/write_bus · d5a5a0ef
      Christoffer Dall 提交于
      Rename mmio_{read,write}_bus to kvm_mmio_{read,write}_bus and export
      them out of mmio.c.
      This will be needed later for the new VGIC implementation.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
      d5a5a0ef
    • H
      arch: fix has_transparent_hugepage() · fd8cfd30
      Hugh Dickins 提交于
      I've just discovered that the useful-sounding has_transparent_hugepage()
      is actually an architecture-dependent minefield: on some arches it only
      builds if CONFIG_TRANSPARENT_HUGEPAGE=y, on others it's also there when
      not, but on some of those (arm and arm64) it then gives the wrong
      answer; and on mips alone it's marked __init, which would crash if
      called later (but so far it has not been called later).
      
      Straighten this out: make it available to all configs, with a sensible
      default in asm-generic/pgtable.h, removing its definitions from those
      arches (arc, arm, arm64, sparc, tile) which are served by the default,
      adding #define has_transparent_hugepage has_transparent_hugepage to
      those (mips, powerpc, s390, x86) which need to override the default at
      runtime, and removing the __init from mips (but maybe that kind of code
      should be avoided after init: set a static variable the first time it's
      called).
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andres Lagar-Cavilla <andreslc@google.com>
      Cc: Yang Shi <yang.shi@linaro.org>
      Cc: Ning Qu <quning@gmail.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: Vineet Gupta <vgupta@synopsys.com>		[arch/arc]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>	[arch/s390]
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fd8cfd30
  4. 13 5月, 2016 2 次提交
    • C
      KVM: halt_polling: provide a way to qualify wakeups during poll · 3491caf2
      Christian Borntraeger 提交于
      Some wakeups should not be considered a sucessful poll. For example on
      s390 I/O interrupts are usually floating, which means that _ALL_ CPUs
      would be considered runnable - letting all vCPUs poll all the time for
      transactional like workload, even if one vCPU would be enough.
      This can result in huge CPU usage for large guests.
      This patch lets architectures provide a way to qualify wakeups if they
      should be considered a good/bad wakeups in regard to polls.
      
      For s390 the implementation will fence of halt polling for anything but
      known good, single vCPU events. The s390 implementation for floating
      interrupts does a wakeup for one vCPU, but the interrupt will be delivered
      by whatever CPU checks first for a pending interrupt. We prefer the
      woken up CPU by marking the poll of this CPU as "good" poll.
      This code will also mark several other wakeup reasons like IPI or
      expired timers as "good". This will of course also mark some events as
      not sucessful. As  KVM on z runs always as a 2nd level hypervisor,
      we prefer to not poll, unless we are really sure, though.
      
      This patch successfully limits the CPU usage for cases like uperf 1byte
      transactional ping pong workload or wakeup heavy workload like OLTP
      while still providing a proper speedup.
      
      This also introduced a new vcpu stat "halt_poll_no_tuning" that marks
      wakeups that are considered not good for polling.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: Radim Krčmář <rkrcmar@redhat.com> (for an earlier version)
      Cc: David Matlack <dmatlack@google.com>
      Cc: Wanpeng Li <kernellwp@gmail.com>
      [Rename config symbol. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3491caf2
    • S
      ARM: Hide finish_arch_post_lock_switch() from modules · ef0491ea
      Steven Rostedt 提交于
      The introduction of switch_mm_irqs_off() brought back an old bug
      regarding the use of preempt_enable_no_resched:
      
      As part of:
      
        62b94a08 ("sched/preempt: Take away preempt_enable_no_resched() from modules")
      
      the definition of preempt_enable_no_resched() is only available in
      built-in code, not in loadable modules, so we can't generally use
      it from header files.
      
      However, the ARM version of finish_arch_post_lock_switch()
      calls preempt_enable_no_resched() and is defined as a static
      inline function in asm/mmu_context.h. This in turn means we cannot
      include asm/mmu_context.h from modules.
      
      With today's tip tree, asm/mmu_context.h gets included from
      linux/mmu_context.h, which is normally the exact pattern one would
      expect, but unfortunately, linux/mmu_context.h can be included from
      the vhost driver that is a loadable module, now causing this compile
      time error with modular configs:
      
        In file included from ../include/linux/mmu_context.h:4:0,
                         from ../drivers/vhost/vhost.c:18:
        ../arch/arm/include/asm/mmu_context.h: In function 'finish_arch_post_lock_switch':
        ../arch/arm/include/asm/mmu_context.h:88:3: error: implicit declaration of function 'preempt_enable_no_resched' [-Werror=implicit-function-declaration]
           preempt_enable_no_resched();
      
      Andy already tried to fix the bug by including linux/preempt.h
      from asm/mmu_context.h, but that didn't help. Arnd suggested reordering
      the header files, which wasn't popular, so let's use this
      workaround instead:
      
      The finish_arch_post_lock_switch() definition is now also hidden
      inside of #ifdef MODULE, so we don't see anything referencing
      preempt_enable_no_resched() from a header file. I've built a
      few hundred randconfig kernels with this, and did not see any
      new problems.
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: linux-arm-kernel@lists.infradead.org
      Fixes: f98db601 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler")
      Link: http://lkml.kernel.org/r/1463146234-161304-1-git-send-email-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ef0491ea
  5. 10 5月, 2016 1 次提交
    • C
      kvm: arm64: Enable hardware updates of the Access Flag for Stage 2 page tables · 06485053
      Catalin Marinas 提交于
      The ARMv8.1 architecture extensions introduce support for hardware
      updates of the access and dirty information in page table entries. With
      VTCR_EL2.HA enabled (bit 21), when the CPU accesses an IPA with the
      PTE_AF bit cleared in the stage 2 page table, instead of raising an
      Access Flag fault to EL2 the CPU sets the actual page table entry bit
      (10). To ensure that kernel modifications to the page table do not
      inadvertently revert a bit set by hardware updates, certain Stage 2
      software pte/pmd operations must be performed atomically.
      
      The main user of the AF bit is the kvm_age_hva() mechanism. The
      kvm_age_hva_handler() function performs a "test and clear young" action
      on the pte/pmd. This needs to be atomic in respect of automatic hardware
      updates of the AF bit. Since the AF bit is in the same position for both
      Stage 1 and Stage 2, the patch reuses the existing
      ptep_test_and_clear_young() functionality if
      __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG is defined. Otherwise, the
      existing pte_young/pte_mkold mechanism is preserved.
      
      The kvm_set_s2pte_readonly() (and the corresponding pmd equivalent) have
      to perform atomic modifications in order to avoid a race with updates of
      the AF bit. The arm64 implementation has been re-written using
      exclusives.
      
      Currently, kvm_set_s2pte_writable() (and pmd equivalent) take a pointer
      argument and modify the pte/pmd in place. However, these functions are
      only used on local variables rather than actual page table entries, so
      it makes more sense to follow the pte_mkwrite() approach for stage 1
      attributes. The change to kvm_s2pte_mkwrite() makes it clear that these
      functions do not modify the actual page table entries.
      
      The (pte|pmd)_mkyoung() uses on Stage 2 entries (setting the AF bit
      explicitly) do not need to be modified since hardware updates of the
      dirty status are not supported by KVM, so there is no possibility of
      losing such information.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      06485053
  6. 09 5月, 2016 1 次提交
  7. 06 5月, 2016 1 次提交
  8. 03 5月, 2016 2 次提交
  9. 28 4月, 2016 8 次提交
  10. 21 4月, 2016 5 次提交
  11. 20 4月, 2016 2 次提交
  12. 08 4月, 2016 2 次提交
  13. 04 4月, 2016 2 次提交
    • A
      ARM: memremap: implement arch_memremap_wb() · 9ab9e4fc
      Ard Biesheuvel 提交于
      The generic memremap() falls back to using ioremap_cache() to create
      MEMREMAP_WB mappings if the requested region is not already covered
      by the linear mapping, unless the architecture provides an implementation
      of arch_memremap_wb().
      
      Since ioremap_cache() is not appropriate on ARM to map memory with the
      same attributes used for the linear mapping, implement arch_memremap_wb()
      which does exactly that. Also, relax the WARN() check to allow MT_MEMORY_RW
      mappings of pfn_valid() pages.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      9ab9e4fc
    • A
      ARM: reintroduce ioremap_cached() for creating cached I/O mappings · 20c5ea4f
      Ard Biesheuvel 提交于
      The original ARM-only ioremap flavor 'ioremap_cached' has been renamed
      to 'ioremap_cache' to align with other architectures, and subsequently
      abused in generic code to map things like firmware tables in memory.
      For that reason, there is currently an effort underway to deprecate
      ioremap_cache, whose semantics are poorly defined, and which is typed
      with an __iomem annotation that is inappropriate for mappings of ordinary
      memory.
      
      However, original users of ioremap_cached() used it in a context where
      the I/O connotation is appropriate, and replacing those instances with
      memremap() does not make sense. So let's revive ioremap_cached(), so
      that we can change back those original users before we drop ioremap_cache
      entirely in favor of memremap.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      20c5ea4f
  14. 26 3月, 2016 1 次提交