1. 20 May, 2016 2 commits
  2. 09 May, 2016 1 commit
    • Catalin Marinas's avatar
      kvm: arm64: Enable hardware updates of the Access Flag for Stage 2 page tables · 06485053
      Catalin Marinas authored
      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: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      06485053
  3. 03 May, 2016 10 commits
  4. 29 Apr, 2016 1 commit
  5. 21 Apr, 2016 17 commits
  6. 06 Apr, 2016 3 commits
    • Sudeep Holla's avatar
      arm64: KVM: unregister notifiers in hyp mode teardown path · 06a71a24
      Sudeep Holla authored
      Commit 1e947bad ("arm64: KVM: Skip HYP setup when already running
      in HYP") re-organized the hyp init code and ended up leaving the CPU
      hotplug and PM notifier even if hyp mode initialization fails.
      
      Since KVM is not yet supported with ACPI, the above mentioned commit
      breaks CPU hotplug in ACPI boot.
      
      This patch fixes teardown_hyp_mode to properly unregister both CPU
      hotplug and PM notifiers in the teardown path.
      
      Fixes: 1e947bad ("arm64: KVM: Skip HYP setup when already running in HYP")
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      06a71a24
    • Marc Zyngier's avatar
      arm64: KVM: Warn when PARange is less than 40 bits · 6141570c
      Marc Zyngier authored
      We always thought that 40bits of PA range would be the minimum people
      would actually build. Anything less is terrifyingly small.
      
      Turns out that we were both right and wrong. Nobody has ever built
      such a system, but the ARM Foundation Model has a PARange set to 36bits.
      Just because we can. Oh well. Now, the KVM API explicitely says that
      we offer a 40bit PA space to the VM, so we shouldn't run KVM on
      the Foundation Model at all.
      
      That being said, this patch offers a less agressive alternative, and
      loudly warns about the configuration being unsupported. You'll still
      be able to run VMs (at your own risks, though).
      
      This is just a workaround until we have a proper userspace API where
      we report the PARange to userspace.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      6141570c
    • Marc Zyngier's avatar
      KVM: arm/arm64: Handle forward time correction gracefully · 1c5631c7
      Marc Zyngier authored
      On a host that runs NTP, corrections can have a direct impact on
      the background timer that we program on the behalf of a vcpu.
      
      In particular, NTP performing a forward correction will result in
      a timer expiring sooner than expected from a guest point of view.
      Not a big deal, we kick the vcpu anyway.
      
      But on wake-up, the vcpu thread is going to perform a check to
      find out whether or not it should block. And at that point, the
      timer check is going to say "timer has not expired yet, go back
      to sleep". This results in the timer event being lost forever.
      
      There are multiple ways to handle this. One would be record that
      the timer has expired and let kvm_cpu_has_pending_timer return
      true in that case, but that would be fairly invasive. Another is
      to check for the "short sleep" condition in the hrtimer callback,
      and restart the timer for the remaining time when the condition
      is detected.
      
      This patch implements the latter, with a bit of refactoring in
      order to avoid too much code duplication.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarAlexander Graf <agraf@suse.de>
      Reviewed-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      1c5631c7
  7. 01 Apr, 2016 1 commit
    • Will Deacon's avatar
      arm64: KVM: Add braces to multi-line if statement in virtual PMU code · 7d4bd1d2
      Will Deacon authored
      The kernel is written in C, not python, so we need braces around
      multi-line if statements. GCC 6 actually warns about this, thanks to the
      fantastic new "-Wmisleading-indentation" flag:
      
       | virt/kvm/arm/pmu.c: In function ‘kvm_pmu_overflow_status’:
       | virt/kvm/arm/pmu.c:198:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
       |    reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
       |    ^~~
       | arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:196:2: note: ...this ‘if’ clause, but it is not
       |   if ((vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
       |   ^~
      
      As it turns out, this particular case is harmless (we just do some &=
      operations with 0), but worth fixing nonetheless.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      7d4bd1d2
  8. 31 Mar, 2016 1 commit
  9. 30 Mar, 2016 1 commit
  10. 26 Mar, 2016 3 commits
    • Linus Torvalds's avatar
      Linux 4.6-rc1 · f55532a0
      Linus Torvalds authored
      f55532a0
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client · d5a38f6e
      Linus Torvalds authored
      Pull Ceph updates from Sage Weil:
       "There is quite a bit here, including some overdue refactoring and
        cleanup on the mon_client and osd_client code from Ilya, scattered
        writeback support for CephFS and a pile of bug fixes from Zheng, and a
        few random cleanups and fixes from others"
      
      [ I already decided not to pull this because of it having been rebased
        recently, but ended up changing my mind after all.  Next time I'll
        really hold people to it.  Oh well.   - Linus ]
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: (34 commits)
        libceph: use KMEM_CACHE macro
        ceph: use kmem_cache_zalloc
        rbd: use KMEM_CACHE macro
        ceph: use lookup request to revalidate dentry
        ceph: kill ceph_get_dentry_parent_inode()
        ceph: fix security xattr deadlock
        ceph: don't request vxattrs from MDS
        ceph: fix mounting same fs multiple times
        ceph: remove unnecessary NULL check
        ceph: avoid updating directory inode's i_size accidentally
        ceph: fix race during filling readdir cache
        libceph: use sizeof_footer() more
        ceph: kill ceph_empty_snapc
        ceph: fix a wrong comparison
        ceph: replace CURRENT_TIME by current_fs_time()
        ceph: scattered page writeback
        libceph: add helper that duplicates last extent operation
        libceph: enable large, variable-sized OSD requests
        libceph: osdc->req_mempool should be backed by a slab pool
        libceph: make r_request msg_size calculation clearer
        ...
      d5a38f6e
    • Linus Torvalds's avatar
      Merge tag 'ofs-pull-tag-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux · 698f415c
      Linus Torvalds authored
      Pull orangefs filesystem from Mike Marshall.
      
      This finally merges the long-pending orangefs filesystem, which has been
      much cleaned up with input from Al Viro over the last six months.  From
      the documentation file:
      
       "OrangeFS is an LGPL userspace scale-out parallel storage system.  It
        is ideal for large storage problems faced by HPC, BigData, Streaming
        Video, Genomics, Bioinformatics.
      
        Orangefs, originally called PVFS, was first developed in 1993 by Walt
        Ligon and Eric Blumer as a parallel file system for Parallel Virtual
        Machine (PVM) as part of a NASA grant to study the I/O patterns of
        parallel programs.
      
        Orangefs features include:
      
          - Distributes file data among multiple file servers
          - Supports simultaneous access by multiple clients
          - Stores file data and metadata on servers using local file system
            and access methods
          - Userspace implementation is easy to install and maintain
          - Direct MPI support
          - Stateless"
      
      see Documentation/filesystems/orangefs.txt for more in-depth details.
      
      * tag 'ofs-pull-tag-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux: (174 commits)
        orangefs: fix orangefs_superblock locking
        orangefs: fix do_readv_writev() handling of error halfway through
        orangefs: have ->kill_sb() evict the VFS side of things first
        orangefs: sanitize ->llseek()
        orangefs-bufmap.h: trim unused junk
        orangefs: saner calling conventions for getting a slot
        orangefs_copy_{to,from}_bufmap(): don't pass bufmap pointer
        orangefs: get rid of readdir_handle_s
        ornagefs: ensure that truncate has an up to date inode size
        orangefs: move code which sets i_link to orangefs_inode_getattr
        orangefs: remove needless wrapper around GFP_KERNEL
        orangefs: remove wrapper around mutex_lock(&inode->i_mutex)
        orangefs: refactor inode type or link_target change detection
        orangefs: use new getattr for revalidate and remove old getattr
        orangefs: use new getattr in inode getattr and permission
        orangefs: use new orangefs_inode_getattr to get size in write and llseek
        orangefs: use new orangefs_inode_getattr to create new inodes
        orangefs: rename orangefs_inode_getattr to orangefs_inode_old_getattr
        orangefs: remove inode->i_lock wrapper
        orangefs: put register_chrdev immediately before register_filesystem
        ...
      698f415c