1. 05 Mar, 2021 8 commits
  2. 04 Mar, 2021 19 commits
  3. 03 Mar, 2021 9 commits
  4. 02 Mar, 2021 4 commits
    • Chen Jun's avatar
      ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount · 999340d5
      Chen Jun authored
      On little endian system, Use aarch64_be(gcc v7.3) downloaded from
      linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y,
      CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y.
      
      gcc will create symbols of _mcount but recordmcount can not create
      mcount_loc for *.o.
      aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount
      00000000000000d0 R_AARCH64_CALL26  _mcount
      ...
      0000000000007190 R_AARCH64_CALL26  _mcount
      
      The reason is than funciton arm64_is_fake_mcount can not work correctly.
      A symbol of _mcount in *.o compiled with big endian compiler likes:
      00 00 00 2d 00 00 01 1b
      w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes
      uint32_t as parameter, which truncates rp->r_info.
      
      Use w8() instead w() to read relp->r_info
      
      Link: https://lkml.kernel.org/r/20210222135840.56250-1-chenjun102@huawei.com
      
      Fixes: ea0eada4 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarChen Jun <chenjun102@huawei.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      999340d5
    • Babu Moger's avatar
      KVM: SVM: Clear the CR4 register on reset · 9e46f6c6
      Babu Moger authored
      This problem was reported on a SVM guest while executing kexec.
      Kexec fails to load the new kernel when the PCID feature is enabled.
      
      When kexec starts loading the new kernel, it starts the process by
      resetting the vCPU's and then bringing each vCPU online one by one.
      The vCPU reset is supposed to reset all the register states before the
      vCPUs are brought online. However, the CR4 register is not reset during
      this process. If this register is already setup during the last boot,
      all the flags can remain intact. The X86_CR4_PCIDE bit can only be
      enabled in long mode. So, it must be enabled much later in SMP
      initialization.  Having the X86_CR4_PCIDE bit set during SMP boot can
      cause a boot failures.
      
      Fix the issue by resetting the CR4 register in init_vmcb().
      Signed-off-by: default avatarBabu Moger <babu.moger@amd.com>
      Message-Id: <161471109108.30811.6392805173629704166.stgit@bmoger-ubuntu>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9e46f6c6
    • David Woodhouse's avatar
      KVM: x86/xen: Add support for vCPU runstate information · 30b5c851
      David Woodhouse authored
      This is how Xen guests do steal time accounting. The hypervisor records
      the amount of time spent in each of running/runnable/blocked/offline
      states.
      
      In the Xen accounting, a vCPU is still in state RUNSTATE_running while
      in Xen for a hypercall or I/O trap, etc. Only if Xen explicitly schedules
      does the state become RUNSTATE_blocked. In KVM this means that even when
      the vCPU exits the kvm_run loop, the state remains RUNSTATE_running.
      
      The VMM can explicitly set the vCPU to RUNSTATE_blocked by using the
      KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT attribute, and can also use
      KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST to retrospectively add a given
      amount of time to the blocked state and subtract it from the running
      state.
      
      The state_entry_time corresponds to get_kvmclock_ns() at the time the
      vCPU entered the current state, and the total times of all four states
      should always add up to state_entry_time.
      Co-developed-by: default avatarJoao Martins <joao.m.martins@oracle.com>
      Signed-off-by: default avatarJoao Martins <joao.m.martins@oracle.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Message-Id: <20210301125309.874953-2-dwmw2@infradead.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      30b5c851
    • David Woodhouse's avatar
      KVM: x86/xen: Fix return code when clearing vcpu_info and vcpu_time_info · 7d7c5f76
      David Woodhouse authored
      When clearing the per-vCPU shared regions, set the return value to zero
      to indicate success. This was causing spurious errors to be returned to
      userspace on soft reset.
      
      Also add a paranoid BUILD_BUG_ON() for compat structure compatibility.
      
      Fixes: 0c165b3c ("KVM: x86/xen: Allow reset of Xen attributes")
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Message-Id: <20210301125309.874953-1-dwmw2@infradead.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7d7c5f76