1. 11 Jan, 2019 1 commit
  2. 04 Jan, 2019 2 commits
    • Joel Fernandes (Google)'s avatar
      mm: treewide: remove unused address argument from pte_alloc functions · 4cf58924
      Joel Fernandes (Google) authored
      Patch series "Add support for fast mremap".
      This series speeds up the mremap(2) syscall by copying page tables at
      the PMD level even for non-THP systems.  There is concern that the extra
      'address' argument that mremap passes to pte_alloc may do something
      subtle architecture related in the future that may make the scheme not
      work.  Also we find that there is no point in passing the 'address' to
      pte_alloc since its unused.  This patch therefore removes this argument
      tree-wide resulting in a nice negative diff as well.  Also ensuring
      along the way that the enabled architectures do not do anything funky
      with the 'address' argument that goes unnoticed by the optimization.
      Build and boot tested on x86-64.  Build tested on arm64.  The config
      enablement patch for arm64 will be posted in the future after more
      The changes were obtained by applying the following Coccinelle script.
      (thanks Julia for answering all Coccinelle questions!).
      Following fix ups were done manually:
      * Removal of address argument from  pte_fragment_alloc
      * Removal of pte_alloc_one_fast definitions from m68k and microblaze.
      // Options: --include-headers --no-includes
      // Note: I split the 'identifier fn' line, so if you are manually
      // running it, please unsplit it so it runs for you.
      virtual patch
      @pte_alloc_func_def depends on patch exists@
      identifier E2;
      identifier fn =~
      type T2;
      - , T2 E2
       { ... }
      @pte_alloc_func_proto_noarg depends on patch exists@
      type T1, T2, T3, T4;
      identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
      - T3 fn(T1, T2);
      + T3 fn(T1);
      - T3 fn(T1, T2, T4);
      + T3 fn(T1, T2);
      @pte_alloc_func_proto depends on patch exists@
      identifier E1, E2, E4;
      type T1, T2, T3, T4;
      identifier fn =~
      - T3 fn(T1 E1, T2 E2);
      + T3 fn(T1 E1);
      - T3 fn(T1 E1, T2 E2, T4 E4);
      + T3 fn(T1 E1, T2 E2);
      @pte_alloc_func_call depends on patch exists@
      expression E2;
      identifier fn =~
      -,  E2
      @pte_alloc_macro depends on patch exists@
      identifier fn =~
      identifier a, b, c;
      expression e;
      position p;
      - #define fn(a, b, c) e
      + #define fn(a, b) e
      - #define fn(a, b) e
      + #define fn(a) e
      Link: http://lkml.kernel.org/r/20181108181201.88826-2-joelaf@google.comSigned-off-by: 's avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Suggested-by: 's avatarKirill A. Shutemov <kirill@shutemov.name>
      Acked-by: 's avatarKirill A. Shutemov <kirill@shutemov.name>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Kirill A. Shutemov <kirill@shutemov.name>
      Cc: William Kucharski <william.kucharski@oracle.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Linus Torvalds's avatar
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds authored
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      There were a couple of notable cases:
       - csky still had the old "verify_area()" name as an alias.
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
       - microblaze used the type argument for a debug printout
      but other than those oddities this should be a total no-op patch.
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 28 Dec, 2018 1 commit
    • Jérôme Glisse's avatar
      mm/mmu_notifier: use structure for invalidate_range_start/end callback · 5d6527a7
      Jérôme Glisse authored
      Patch series "mmu notifier contextual informations", v2.
      This patchset adds contextual information, why an invalidation is
      happening, to mmu notifier callback.  This is necessary for user of mmu
      notifier that wish to maintains their own data structure without having to
      add new fields to struct vm_area_struct (vma).
      For instance device can have they own page table that mirror the process
      address space.  When a vma is unmap (munmap() syscall) the device driver
      can free the device page table for the range.
      Today we do not have any information on why a mmu notifier call back is
      happening and thus device driver have to assume that it is always an
      munmap().  This is inefficient at it means that it needs to re-allocate
      device page table on next page fault and rebuild the whole device driver
      data structure for the range.
      Other use case beside munmap() also exist, for instance it is pointless
      for device driver to invalidate the device page table when the
      invalidation is for the soft dirtyness tracking.  Or device driver can
      optimize away mprotect() that change the page table permission access for
      the range.
      This patchset enables all this optimizations for device drivers.  I do not
      include any of those in this series but another patchset I am posting will
      leverage this.
      The patchset is pretty simple from a code point of view.  The first two
      patches consolidate all mmu notifier arguments into a struct so that it is
      easier to add/change arguments.  The last patch adds the contextual
      information (munmap, protection, soft dirty, clear, ...).
      This patch (of 3):
      To avoid having to change many callback definition everytime we want to
      add a parameter use a structure to group all parameters for the
      mmu_notifier invalidate_range_start/end callback.  No functional changes
      with this patch.
      [akpm@linux-foundation.org: fix drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c kerneldoc]
      Link: http://lkml.kernel.org/r/20181205053628.3210-2-jglisse@redhat.comSigned-off-by: 's avatarJérôme Glisse <jglisse@redhat.com>
      Acked-by: 's avatarJan Kara <jack@suse.cz>
      Acked-by: Jason Gunthorpe <jgg@mellanox.com>	[infiniband]
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Ross Zwisler <zwisler@kernel.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krcmar <rkrcmar@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Christian Koenig <christian.koenig@amd.com>
      Cc: Felix Kuehling <felix.kuehling@amd.com>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 21 Dec, 2018 5 commits
  5. 19 Dec, 2018 8 commits
    • Marc Zyngier's avatar
      arm/arm64: KVM: Add ARM_EXCEPTION_IS_TRAP macro · 58466766
      Marc Zyngier authored
      32 and 64bit use different symbols to identify the traps.
      32bit has a fine grained approach (prefetch abort, data abort and HVC),
      while 64bit is pretty happy with just "trap".
      This has been fine so far, except that we now need to decode some
      of that in tracepoints that are common to both architectures.
      Introduce ARM_EXCEPTION_IS_TRAP which abstracts the trap symbols
      and make the tracepoint use it.
      Acked-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Christoffer Dall's avatar
      KVM: arm/arm64: Fix unintended stage 2 PMD mappings · 6794ad54
      Christoffer Dall authored
      There are two things we need to take care of when we create block
      mappings in the stage 2 page tables:
        (1) The alignment within a PMD between the host address range and the
        guest IPA range must be the same, since otherwise we end up mapping
        pages with the wrong offset.
        (2) The head and tail of a memory slot may not cover a full block
        size, and we have to take care to not map those with block
        descriptors, since we could expose memory to the guest that the host
        did not intend to expose.
      So far, we have been taking care of (1), but not (2), and our commentary
      describing (1) was somewhat confusing.
      This commit attempts to factor out the checks of both into a common
      function, and if we don't pass the check, we won't attempt any PMD
      mappings for neither hugetlbfs nor THP.
      Note that we used to only check the alignment for THP, not for
      hugetlbfs, but as far as I can tell the check needs to be applied to
      both scenarios.
      Cc: Ralph Palutke <ralph.palutke@fau.de>
      Cc: Lukas Braun <koomi@moshbit.net>
      Reported-by: 's avatarLukas Braun <koomi@moshbit.net>
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      arm/arm64: KVM: vgic: Force VM halt when changing the active state of GICv3 PPIs/SGIs · 107352a2
      Marc Zyngier authored
      We currently only halt the guest when a vCPU messes with the active
      state of an SPI. This is perfectly fine for GICv2, but isn't enough
      for GICv3, where all vCPUs can access the state of any other vCPU.
      Let's broaden the condition to include any GICv3 interrupt that
      has an active state (i.e. all but LPIs).
      Cc: stable@vger.kernel.org
      Reviewed-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Christoffer Dall's avatar
      KVM: arm/arm64: arch_timer: Simplify kvm_timer_vcpu_terminate · 6e14ef1d
      Christoffer Dall authored
      kvm_timer_vcpu_terminate can only be called in two scenarios:
       1. As part of cleanup during a failed VCPU create
       2. As part of freeing the whole VM (struct kvm refcount == 0)
      In the first case, we cannot have programmed any timers or mapped any
      IRQs, and therefore we do not have to cancel anything or unmap anything.
      In the second case, the VCPU will have gone through kvm_timer_vcpu_put,
      which will have canceled the emulated physical timer's hrtimer, and we
      do not need to that here as well.  We also do not care if the irq is
      recorded as mapped or not in the VGIC data structure, because the whole
      VM is going away.  That leaves us only with having to ensure that we
      cancel the bg_timer if we were blocking the last time we called
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Christoffer Dall's avatar
      KVM: arm/arm64: Remove arch timer workqueue · 8a411b06
      Christoffer Dall authored
      The use of a work queue in the hrtimer expire function for the bg_timer
      is a leftover from the time when we would inject interrupts when the
      bg_timer expired.
      Since we are no longer doing that, we can instead call
      kvm_vcpu_wake_up() directly from the hrtimer function and remove all
      workqueue functionality from the arch timer code.
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Christoffer Dall's avatar
      KVM: arm/arm64: Fixup the kvm_exit tracepoint · 71a7e47f
      Christoffer Dall authored
      The kvm_exit tracepoint strangely always reported exits as being IRQs.
      This seems to be because either the __print_symbolic or the tracepoint
      macros use a variable named idx.
      Take this chance to update the fields in the tracepoint to reflect the
      concepts in the arm64 architecture that we pass to the tracepoint and
      move the exception type table to the same location and header files as
      the exits code.
      We also clear out the exception code to 0 for IRQ exits (which
      translates to UNKNOWN in text) to make it slighyly less confusing to
      parse the trace output.
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Christoffer Dall's avatar
      KVM: arm/arm64: vgic: Consider priority and active state for pending irq · 9009782a
      Christoffer Dall authored
      When checking if there are any pending IRQs for the VM, consider the
      active state and priority of the IRQs as well.
      Otherwise we could be continuously scheduling a guest hypervisor without
      it seeing an IRQ.
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
    • Gustavo A. R. Silva's avatar
      KVM: arm/arm64: vgic: Fix off-by-one bug in vgic_get_irq() · c23b2e6f
      Gustavo A. R. Silva authored
      When using the nospec API, it should be taken into account that:
      "...if the CPU speculates past the bounds check then
       * array_index_nospec() will clamp the index within the range of [0,
       * size)."
      The above is part of the header for macro array_index_nospec() in
      Now, in this particular case, if intid evaluates to exactly VGIC_MAX_SPI
      or to exaclty VGIC_MAX_PRIVATE, the array_index_nospec() macro ends up
      returning VGIC_MAX_SPI - 1 or VGIC_MAX_PRIVATE - 1 respectively, instead
      of VGIC_MAX_SPI or VGIC_MAX_PRIVATE, which, based on the original logic:
      	/* SGIs and PPIs */
      	if (intid <= VGIC_MAX_PRIVATE)
       		return &vcpu->arch.vgic_cpu.private_irqs[intid];
       	/* SPIs */
      	if (intid <= VGIC_MAX_SPI)
       		return &kvm->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];
      are valid values for intid.
      Fix this by calling array_index_nospec() macro with VGIC_MAX_PRIVATE + 1
      and VGIC_MAX_SPI + 1 as arguments for its parameter size.
      Fixes: 41b87599 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()")
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      [dropped the SPI part which was fixed separately]
      Signed-off-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
  6. 18 Dec, 2018 16 commits
  7. 14 Dec, 2018 3 commits
    • Paolo Bonzini's avatar
      kvm: introduce manual dirty log reprotect · 2a31b9db
      Paolo Bonzini authored
      There are two problems with KVM_GET_DIRTY_LOG.  First, and less important,
      it can take kvm->mmu_lock for an extended period of time.  Second, its user
      can actually see many false positives in some cases.  The latter is due
      to a benign race like this:
        1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
        2. The guest modifies the pages, causing them to be marked ditry.
        3. Userspace actually copies the pages.
        4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
           they were not written to since (3).
      This is especially a problem for large guests, where the time between
      (1) and (3) can be substantial.  This patch introduces a new
      capability which, when enabled, makes KVM_GET_DIRTY_LOG not
      write-protect the pages it returns.  Instead, userspace has to
      explicitly clear the dirty log bits just before using the content
      of the page.  The new KVM_CLEAR_DIRTY_LOG ioctl can also operate on a
      64-page granularity rather than requiring to sync a full memslot;
      this way, the mmu_lock is taken for small amounts of time, and
      only a small amount of time will pass between write protection
      of pages and the sending of their content.
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
    • Paolo Bonzini's avatar
      kvm: rename last argument to kvm_get_dirty_log_protect · 8fe65a82
      Paolo Bonzini authored
      When manual dirty log reprotect will be enabled, kvm_get_dirty_log_protect's
      pointer argument will always be false on exit, because no TLB flush is needed
      until the manual re-protection operation.  Rename it from "is_dirty" to "flush",
      which more accurately tells the caller what they have to do with it.
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
    • Paolo Bonzini's avatar
      kvm: make KVM_CAP_ENABLE_CAP_VM architecture agnostic · e5d83c74
      Paolo Bonzini authored
      The first such capability to be handled in virt/kvm/ will be manual
      dirty page reprotection.
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  8. 10 Dec, 2018 1 commit
  9. 12 Nov, 2018 1 commit
  10. 26 Oct, 2018 1 commit
  11. 18 Oct, 2018 1 commit