- 12 1月, 2021 40 次提交
-
-
由 chenjiajun 提交于
virt inclusion category: feature bugzilla: 46853 CVE: NA This patch export cpu time related items to vcpu_stat. Contain: steal, st_max, utime, stime, gtime The definitions of these items are: steal: cpu time VCPU waits for PCPU while it is servicing another VCPU st_max: max scheduling delay utime: cpu time in userspace stime: cpu time in sys gtime: cpu time in guest Through these items, user can get many cpu usage info of vcpu, such as: CPU Usage of Guest = gtime_delta / delta_cputime CPU Usage of Hyp = (utime_delta - gtime_delta + stime_delta) / delta_cputime CPU Usage of Steal = steal_delta / delta_cputime Max Scheduling Delay = st_max Signed-off-by: Nliangpeng <liangpeng10@huawei.com> Signed-off-by: Nchenjiajun <chenjiajun8@huawei.com> Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 chenjiajun 提交于
virt inclusion category: feature bugzilla: 46853 CVE: NA This patch export remaining aarch64 exit items to vcpu_stat via debugfs. The items include: fp_asimd_exit_stat, irq_exit_stat, sys64_exit_stat, mabt_exit_stat, fail_entry_exit_stat, internal_error_exit_stat, unknown_ec_exit_stat, cp15_32_exit_stat, cp15_64_exit_stat, cp14_mr_exit_stat, cp14_ls_exit_stat, cp14_64_exit_stat, smc_exit_stat, sve_exit_stat, debug_exit_stat Signed-off-by: NBiaoxiang Ye <yebiaoxiang@huawei.com> Signed-off-by: NZengruan Ye <yezengruan@huawei.com> Signed-off-by: Nchenjiajun <chenjiajun8@huawei.com> Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 chenjiajun 提交于
virt inclusion category: feature bugzilla: 46853 CVE: NA This patch create debugfs entry for vcpu stat. The entry path is /sys/kernel/debug/kvm/vcpu_stat. And vcpu_stat contains partial kvm exits items of vcpu, include: pid, hvc_exit_stat, wfe_exit_stat, wfi_exit_stat, mmio_exit_user, mmio_exit_kernel, exits Currently, The maximum vcpu limit is 1024. From this vcpu_stat, user can get the number of these kvm exits items over a period of time, which is helpful to monitor the virtual machine. Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: Nchenjiajun <chenjiajun8@huawei.com> Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Mingwang Li 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA When mapping the HVA to HPA above, it doesn't know that the PTE writeable of stage2 is "!memslot_is_readonly(slot)". This may causes the difference between the writability of HVA->HPA and GPA->HPA. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NMingwang Li <limingwang@huawei.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA Add kvm config in defconfig Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Atish Patra 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA The KVM host kernel is running in HS-mode needs so we need to handle the SBI calls coming from guest kernel running in VS-mode. This patch adds SBI v0.1 support in KVM RISC-V. Almost all SBI v0.1 calls are implemented in KVM kernel module except GETCHAR and PUTCHART calls which are forwarded to user space because these calls cannot be implemented in kernel space. In future, when we implement SBI v0.2 for Guest, we will forward SBI v0.2 experimental and vendor extension calls to user space. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAtish Patra <atish.patra@wdc.com> Signed-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Atish Patra 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA Add a KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctl interface for floating point registers such as F0-F31 and FCSR. This support is added for both 'F' and 'D' extensions. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAtish Patra <atish.patra@wdc.com> Signed-off-by: NAnup Patel <anup.patel@wdc.com> Signed-off-by: NMingwang Li <limingwang@huawei.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Atish Patra 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch adds floating point (F and D extension) context save/restore for guest VCPUs. The FP context is saved and restored lazily only when kernel enter/exits the in-kernel run loop and not during the KVM world switch. This way FP save/restore has minimal impact on KVM performance. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAtish Patra <atish.patra@wdc.com> Signed-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Atish Patra 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA The RISC-V hypervisor specification doesn't have any virtual timer feature. Due to this, the guest VCPU timer will be programmed via SBI calls. The host will use a separate hrtimer event for each guest VCPU to provide timer functionality. We inject a virtual timer interrupt to the guest VCPU whenever the guest VCPU hrtimer event expires. This patch adds guest VCPU timer implementation along with ONE_REG interface to access VCPU timer state from user space. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAtish Patra <atish.patra@wdc.com> Signed-off-by: NAnup Patel <anup.patel@wdc.com> Signed-off-by: NMingwang Li <limingwang@huawei.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch implements MMU notifiers for KVM RISC-V so that Guest physical address space is in-sync with Host physical address space. This will allow swapping, page migration, etc to work transparently with KVM RISC-V. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch implements all required functions for programming the stage2 page table for each Guest/VM. At high-level, the flow of stage2 related functions is similar from KVM ARM/ARM64 implementation but the stage2 page table format is quite different for KVM RISC-V. Reference: https://gitee.com/openeuler/kernel/issues/I26X9V [jiangyifei: stage2 dirty log support] Signed-off-by: NYifei Jiang <jiangyifei@huawei.com> Signed-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA We implement a simple VMID allocator for Guests/VMs which: 1. Detects number of VMID bits at boot-time 2. Uses atomic number to track VMID version and increments VMID version whenever we run-out of VMIDs 3. Flushes Guest TLBs on all host CPUs whenever we run-out of VMIDs 4. Force updates HW Stage2 VMID for each Guest VCPU whenever VMID changes using VCPU request KVM_REQ_UPDATE_HGATP Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA We get illegal instruction trap whenever Guest/VM executes WFI instruction. This patch handles WFI trap by blocking the trapped VCPU using kvm_vcpu_block() API. The blocked VCPU will be automatically resumed whenever a VCPU interrupt is injected from user-space or from in-kernel IRQCHIP emulation. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 bugzilla: NA CVE: NA We will get stage2 page faults whenever Guest/VM access SW emulated MMIO device or unmapped Guest RAM. This patch implements MMIO read/write emulation by extracting MMIO details from the trapped load/store instruction and forwarding the MMIO read/write to user-space. The actual MMIO emulation will happen in user-space and KVM kernel module will only take care of register updates before resuming the trapped VCPU. The handling for stage2 page faults for unmapped Guest RAM will be implemeted by a separate patch later. Reference: https://gitee.com/openeuler/kernel/issues/I26X9V [jiangyifei: ioeventfd and in-kernel mmio device support] Signed-off-by: NYifei Jiang <jiangyifei@huawei.com> Signed-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch implements the VCPU world-switch for KVM RISC-V. The KVM RISC-V world-switch (i.e. __kvm_riscv_switch_to()) mostly switches general purpose registers, SSTATUS, STVEC, SSCRATCH and HSTATUS CSRs. Other CSRs are switched via vcpu_load() and vcpu_put() interface in kvm_arch_vcpu_load() and kvm_arch_vcpu_put() functions respectively. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA For KVM RISC-V, we use KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls to access VCPU config and registers from user-space. We have three types of VCPU registers: 1. CONFIG - these are VCPU config and capabilities 2. CORE - these are VCPU general purpose registers 3. CSR - these are VCPU control and status registers The CONFIG register available to user-space is ISA. The ISA register is a read and write register where user-space can only write the desired VCPU ISA capabilities before running the VCPU. The CORE registers available to user-space are PC, RA, SP, GP, TP, A0-A7, T0-T6, S0-S11 and MODE. Most of these are RISC-V general registers except PC and MODE. The PC register represents program counter whereas the MODE register represent VCPU privilege mode (i.e. S/U-mode). The CSRs available to user-space are SSTATUS, SIE, STVEC, SSCRATCH, SEPC, SCAUSE, STVAL, SIP, and SATP. All of these are read/write registers. In future, more VCPU register types will be added (such as FP) for the KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch implements VCPU interrupts and requests which are both asynchronous events. The VCPU interrupts can be set/unset using KVM_INTERRUPT ioctl from user-space. In future, the in-kernel IRQCHIP emulation will use kvm_riscv_vcpu_set_interrupt() and kvm_riscv_vcpu_unset_interrupt() functions to set/unset VCPU interrupts. Important VCPU requests implemented by this patch are: KVM_REQ_SLEEP - set whenever VCPU itself goes to sleep state KVM_REQ_VCPU_RESET - set whenever VCPU reset is requested The WFI trap-n-emulate (added later) will use KVM_REQ_SLEEP request and kvm_riscv_vcpu_has_interrupt() function. The KVM_REQ_VCPU_RESET request will be used by SBI emulation (added later) to power-up a VCPU in power-off state. The user-space can use the GET_MPSTATE/SET_MPSTATE ioctls to get/set power state of a VCPU. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch implements VCPU create, init and destroy functions required by generic KVM module. We don't have much dynamic resources in struct kvm_vcpu_arch so these functions are quite simple for KVM RISC-V. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch adds initial skeletal KVM RISC-V support which has: 1. A simple implementation of arch specific VM functions except kvm_vm_ioctl_get_dirty_log() which will implemeted in-future as part of stage2 page loging. 2. Stubs of required arch specific VCPU functions except kvm_arch_vcpu_ioctl_run() which is semi-complete and extended by subsequent patches. 3. Stubs for required arch specific stage2 MMU functions. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch extends asm/csr.h by adding RISC-V hypervisor extension related defines. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAlexander Graf <graf@amazon.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch enables essential drivers for Microchip PolarFire ICICLE board. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch adds initial DTS for Microchip ICICLE board having only essential devcies (clocks, sdhci, ethernet, serial, etc). Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This patch adds Microchip PolarFire kconfig option which selects SoC specific drivers. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA Add cpu hotplug config in defconfigs Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Alistair Francis 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA This reverts commit d4c08b97. The latest RISC-V 32bit glibc submission doesn't work with this patch, so let's revert it. This revert can be reverted when the glibc submission is updated to work on the 5.1 kernel. Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAlistair Francis <alistair.francis@wdc.com> Upstream-Status: Inappropriate [enable feature] Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Anup Patel 提交于
euleros inclusion category: feature feature: initial KVM RISC-V support bugzilla: 46845 CVE: NA Various Linux kernel DEBUG options have big performance impact so these should not be enabled in RISC-V normal defconfigs. Instead we should have separate RISC-V fragmented config for enabling these DEBUG options. This way Linux RISC-V kernel can be built for both non-debug and debug purposes using same defconfig. This patch moves additional DEBUG options to extra_debug.config. To configure a non-debug RV64 kernel, we use our normal defconfig: $ make O=<linux_build_directory> defconfig Wherease to configure a debug RV64 kernel, we use extra_debug.config: $ make O=<linux_build_directory> defconfig extra_debug.config Reference: https://gitee.com/openeuler/kernel/issues/I26X9VSigned-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NYifei Jiang <jiangyifei@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Yazen Ghannam 提交于
stable inclusion from stable-5.10.4 commit 700d098acec5271161606f3c0086b71695ea2ef8 bugzilla: 46903 -------------------------------- [ Upstream commit 028c221e ] AMD systems provide a "NodeId" value that represents a global ID indicating to which "Node" a logical CPU belongs. The "Node" is a physical structure equivalent to a Die, and it should not be confused with logical structures like NUMA nodes. Logical nodes can be adjusted based on firmware or other settings whereas the physical nodes/dies are fixed based on hardware topology. The NodeId value can be used when a physical ID is needed by software. Save the AMD NodeId to struct cpuinfo_x86.cpu_die_id. Use the value from CPUID or MSR as appropriate. Default to phys_proc_id otherwise. Do so for both AMD and Hygon systems. Drop the node_id parameter from cacheinfo_*_init_llc_id() as it is no longer needed. Update the x86 topology documentation. Suggested-by: NBorislav Petkov <bp@alien8.de> Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201109210659.754018-2-Yazen.Ghannam@amd.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Steven Rostedt (VMware) 提交于
stable inclusion from stable-5.10.4 commit 2bbb32065694dc5e66a028f91d69a6bf592be430 bugzilla: 46903 -------------------------------- commit adab66b7 upstream. It was believed that metag was the only architecture that required the ring buffer to keep 8 byte words aligned on 8 byte architectures, and with its removal, it was assumed that the ring buffer code did not need to handle this case. It appears that sparc64 also requires this. The following was reported on a sparc64 boot up: kernel: futex hash table entries: 65536 (order: 9, 4194304 bytes, linear) kernel: Running postponed tracer tests: kernel: Testing tracer function: kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140 kernel: Kernel unaligned access at TPC[552a24] trace_function+0x44/0x140 kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140 kernel: Kernel unaligned access at TPC[552a24] trace_function+0x44/0x140 kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140 kernel: PASSED Need to put back the 64BIT aligned code for the ring buffer. Link: https://lore.kernel.org/r/CADxRZqzXQRYgKc=y-KV=S_yHL+Y8Ay2mh5ezeZUnpRvg+syWKw@mail.gmail.com Cc: stable@vger.kernel.org Fixes: 86b3de60 ("ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS") Reported-by: NAnatoly Pugachev <matorola@gmail.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Johannes Berg 提交于
stable inclusion from stable-5.10.4 commit ef82413937d1656ff1b74310bb5496b18df1520e bugzilla: 46903 -------------------------------- commit ff9632d2 upstream. Since the time-travel rework, basic time-travel mode hasn't worked properly, but there's no longer a need for this WARN_ON() so just remove it and thereby fix things. Cc: stable@vger.kernel.org Fixes: 4b786e24 ("um: time-travel: Rewrite as an event scheduler") Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Anton Ivanov 提交于
stable inclusion from stable-5.10.4 commit c4b425322134e2ee2950bc1ca54a66511a1526a9 bugzilla: 46903 -------------------------------- commit 97be7cea upstream. asprintf is not compatible with the existing uml memory allocation mechanism. Its use on the "user" side of UML results in a corrupt slab state. Fixes: 0d4e5ac7 ("um: remove uses of variable length arrays") Cc: stable@vger.kernel.org Signed-off-by: NAnton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 David Hildenbrand 提交于
stable inclusion from stable-5.10.4 commit cd2eda58ea0312645c8859945ff43e1fd3d6945f bugzilla: 46903 -------------------------------- commit d6718941 upstream. It's very easy to crash the kernel right now by simply trying to enable memtrace concurrently, hammering on the "enable" interface loop.sh: #!/bin/bash dmesg --console-off while true; do echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable done [root@localhost ~]# loop.sh & [root@localhost ~]# loop.sh & Resulting quickly in a kernel crash. Let's properly protect using a mutex. Fixes: 9d5171a8 ("powerpc/powernv: Enable removal of memory for in memory tracing") Cc: stable@vger.kernel.org# v4.14+ Signed-off-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NOscar Salvador <osalvador@suse.de> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201111145322.15793-3-david@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 David Hildenbrand 提交于
stable inclusion from stable-5.10.4 commit 4b8dcb006e181af228bd913926a4a39a19507848 bugzilla: 46903 -------------------------------- commit c74cf7a3 upstream. We currently leak kernel memory to user space, because memory offlining doesn't do any implicit clearing of memory and we are missing explicit clearing of memory. Let's keep it simple and clear pages before removing the linear mapping. Reproduced in QEMU/TCG with 10 GiB of main memory: [root@localhost ~]# dd obs=9G if=/dev/urandom of=/dev/null [... wait until "free -m" used counter no longer changes and cancel] 19665802+0 records in 1+0 records out 9663676416 bytes (9.7 GB, 9.0 GiB) copied, 135.548 s, 71.3 MB/s [root@localhost ~]# cat /sys/devices/system/memory/block_size_bytes 40000000 [root@localhost ~]# echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable [ 402.978663][ T1086] page:000000001bc4bc74 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24900 [ 402.980063][ T1086] flags: 0x7ffff000001000(reserved) [ 402.980415][ T1086] raw: 007ffff000001000 c00c000000924008 c00c000000924008 0000000000000000 [ 402.980627][ T1086] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 402.980845][ T1086] page dumped because: unmovable page [ 402.989608][ T1086] Offlined Pages 16384 [ 403.324155][ T1086] memtrace: Allocated trace memory on node 0 at 0x0000000200000000 Before this patch: [root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace | head 00000000 c8 25 72 51 4d 26 36 c5 5c c2 56 15 d5 1a cd 10 |.%rQM&6.\.V.....| 00000010 19 b9 50 b2 cb e3 60 b8 ec 0a f3 ec 4b 3c 39 f0 |..P...`.....K<9.|$ 00000020 4e 5a 4c cf bd 26 19 ff 37 79 13 67 24 b7 b8 57 |NZL..&..7y.g$..W|$ 00000030 98 3e f5 be 6f 14 6a bd a4 52 bc 6e e9 e0 c1 5d |.>..o.j..R.n...]|$ 00000040 76 b3 ae b5 88 d7 da e3 64 23 85 2c 10 88 07 b6 |v.......d#.,....|$ 00000050 9a d8 91 de f7 50 27 69 2e 64 9c 6f d3 19 45 79 |.....P'i.d.o..Ey|$ 00000060 6a 6f 8a 61 71 19 1f c7 f1 df 28 26 ca 0f 84 55 |jo.aq.....(&...U|$ 00000070 01 3f be e4 e2 e1 da ff 7b 8c 8e 32 37 b4 24 53 |.?......{..27.$S|$ 00000080 1b 70 30 45 56 e6 8c c4 0e b5 4c fb 9f dd 88 06 |.p0EV.....L.....|$ 00000090 ef c4 18 79 f1 60 b1 5c 79 59 4d f4 36 d7 4a 5c |...y.`.\yYM.6.J\|$ After this patch: [root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace | head 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 40000000 Fixes: 9d5171a8 ("powerpc/powernv: Enable removal of memory for in memory tracing") Cc: stable@vger.kernel.org # v4.14+ Reported-by: NMichael Ellerman <mpe@ellerman.id.au> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NOscar Salvador <osalvador@suse.de> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201111145322.15793-2-david@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Alexey Kardashevskiy 提交于
stable inclusion from stable-5.10.4 commit 8fe4bee4c0f65eac069998ba91595756309a2970 bugzilla: 46903 -------------------------------- commit b1198a88 upstream. We execute certain NPU2 setup code (such as mapping an LPID to a device in NPU2) unconditionally if an Nvlink bridge is detected. However this cannot succeed on POWER8NVL machines and errors appear in dmesg. This is harmless as skiboot returns an error and the only place we check it is vfio-pci but that code does not get called on P8+ either. This adds a check if pnv_npu2_xxx helpers are called on a machine with NPU2 which initializes pnv_phb::npu in pnv_npu2_init(); pnv_phb::npu==NULL on POWER8/NVL (Naples). While at this, fix NULL derefencing in pnv_npu_peers_take_ownership/ pnv_npu_peers_release_ownership which occurs when GPUs on mentioned P8s cause EEH which happens if "vfio-pci" disables devices using the D3 power state; the vfio-pci's disable_idle_d3 module parameter controls this and must be set on Naples. The EEH handling clears the entire pnv_ioda_pe struct in pnv_ioda_free_pe() hence the NULL derefencing. We cannot recover from that but at least we stop crashing. Tested on - POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm, NVIDIA GV100 10de:1db1 driver 418.39 - POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm, NVIDIA P100 10de:15f9 driver 396.47 Fixes: 1b785611 ("powerpc/powernv/npu: Add release_ownership hook") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201122073828.15446-1-aik@ozlabs.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.4 commit 600ebd043469bae31ad133cca77ef64fee2f168d bugzilla: 46903 -------------------------------- commit 17179aeb upstream. MMU_FTR_TYPE_44x cannot be checked by cpu_has_feature() Use mmu_has_feature() instead Fixes: 23eb7f56 ("powerpc: Convert flush_icache_range & friends to C") Cc: stable@vger.kernel.org Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/ceede82fadf37f3b8275e61fcf8cf29a3e2ec7fe.1602351011.git.christophe.leroy@csgroup.euSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.4 commit a8b871dfacfb4d5c3a10599d418520ca8a44ddb3 bugzilla: 46903 -------------------------------- commit 1e78f723 upstream. When SMC1 is relocated and early debug is selected, the board hangs is ppc_md.setup_arch(). This is because ones the microcode has been loaded and SMC1 relocated, early debug writes in the weed. To allow smooth continuation, the SMC1 parameter RAM set up by the bootloader have to be copied into the new location. Fixes: 43db76f4 ("powerpc/8xx: Add microcode patch to move SMC parameter RAM.") Cc: stable@vger.kernel.org Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/b2f71f39eca543f1e4ec06596f09a8b12235c701.1607076683.git.christophe.leroy@csgroup.euSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.4 commit 8bc125f596d166005f90835314d07c2fd735f6d6 bugzilla: 46903 -------------------------------- commit 7c6c86b3 upstream. Since some time now, printk() adds carriage return, leading to unusable xmon output if there is no udbg backend available: [ 54.288722] sysrq: Entering xmon [ 54.292209] Vector: 0 at [cace3d2c] [ 54.292274] pc: [ 54.292331] c0023650 [ 54.292468] : xmon+0x28/0x58 [ 54.292519] [ 54.292574] lr: [ 54.292630] c0023724 [ 54.292749] : sysrq_handle_xmon+0xa4/0xfc [ 54.292801] [ 54.292867] sp: cace3de8 [ 54.292931] msr: 9032 [ 54.292999] current = 0xc28d0000 [ 54.293072] pid = 377, comm = sh [ 54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty (root@po17688vm.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020 [ 54.293287] enter ? for help [ 54.293470] [cace3de8] [ 54.293532] c0023724 [ 54.293654] sysrq_handle_xmon+0xa4/0xfc [ 54.293711] (unreliable) ... [ 54.296002] [ 54.296159] --- Exception: c01 (System Call) at [ 54.296217] 0fd4e784 [ 54.296303] [ 54.296375] SP (7fca6ff0) is in userspace [ 54.296431] mon> [ 54.296484] <no input ...> Use pr_cont() instead. Fixes: 4bcc595c ("printk: reinstate KERN_CONT for printing continuation lines") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> [mpe: Mention that it only happens when udbg is not available] Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/c8a6ec704416ecd5ff2bd26213c9bc026bdd19de.1607077340.git.christophe.leroy@csgroup.euSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.4 commit 2ae45223e46b49314a957d00292b4d7d2f61a1b7 bugzilla: 46903 -------------------------------- commit 197493af upstream. G2_LE has a 603 core, add CPU_FTR_NOEXECUTE. Fixes: 385e89d5 ("powerpc/mm: add exec protection on powerpc 603") Cc: stable@vger.kernel.org Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/39a530ee41d83f49747ab3af8e39c056450b9b4d.1602489653.git.christophe.leroy@csgroup.euSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.4 commit fe534d76d450b9b80481ac5fd620fc97cb977249 bugzilla: 46903 -------------------------------- commit 1891ef21 upstream. fls() and fls64() are using __builtin_ctz() and _builtin_ctzll(). On powerpc, those builtins trivially use ctlzw and ctlzd power instructions. Allthough those instructions provide the expected result with input argument 0, __builtin_ctz() and __builtin_ctzll() are documented as undefined for value 0. The easiest fix would be to use fls() and fls64() functions defined in include/asm-generic/bitops/builtin-fls.h and include/asm-generic/bitops/fls64.h, but GCC output is not optimal: 00000388 <testfls>: 388: 2c 03 00 00 cmpwi r3,0 38c: 41 82 00 10 beq 39c <testfls+0x14> 390: 7c 63 00 34 cntlzw r3,r3 394: 20 63 00 20 subfic r3,r3,32 398: 4e 80 00 20 blr 39c: 38 60 00 00 li r3,0 3a0: 4e 80 00 20 blr 000003b0 <testfls64>: 3b0: 2c 03 00 00 cmpwi r3,0 3b4: 40 82 00 1c bne 3d0 <testfls64+0x20> 3b8: 2f 84 00 00 cmpwi cr7,r4,0 3bc: 38 60 00 00 li r3,0 3c0: 4d 9e 00 20 beqlr cr7 3c4: 7c 83 00 34 cntlzw r3,r4 3c8: 20 63 00 20 subfic r3,r3,32 3cc: 4e 80 00 20 blr 3d0: 7c 63 00 34 cntlzw r3,r3 3d4: 20 63 00 40 subfic r3,r3,64 3d8: 4e 80 00 20 blr When the input of fls(x) is a constant, just check x for nullity and return either 0 or __builtin_clz(x). Otherwise, use cntlzw instruction directly. For fls64() on PPC64, do the same but with __builtin_clzll() and cntlzd instruction. On PPC32, lets take the generic fls64() which will use our fls(). The result is as expected: 00000388 <testfls>: 388: 7c 63 00 34 cntlzw r3,r3 38c: 20 63 00 20 subfic r3,r3,32 390: 4e 80 00 20 blr 000003a0 <testfls64>: 3a0: 2c 03 00 00 cmpwi r3,0 3a4: 40 82 00 10 bne 3b4 <testfls64+0x14> 3a8: 7c 83 00 34 cntlzw r3,r4 3ac: 20 63 00 20 subfic r3,r3,32 3b0: 4e 80 00 20 blr 3b4: 7c 63 00 34 cntlzw r3,r3 3b8: 20 63 00 40 subfic r3,r3,64 3bc: 4e 80 00 20 blr Fixes: 2fcff790 ("powerpc: Use builtin functions for fls()/__fls()/fls64()") Cc: stable@vger.kernel.org Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Acked-by: NSegher Boessenkool <segher@kernel.crashing.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/348c2d3f19ffcff8abe50d52513f989c4581d000.1603375524.git.christophe.leroy@csgroup.euSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Tyrel Datwyler 提交于
stable inclusion from stable-5.10.4 commit e02baf91c7ccb463768a6a1349505f5049c96029 bugzilla: 46903 -------------------------------- commit f10881a4 upstream. Commit bd59380c ("powerpc/rtas: Restrict RTAS requests from userspace") introduced the following error when invoking the errinjct userspace tool: [root@ltcalpine2-lp5 librtas]# errinjct open [327884.071171] sys_rtas: RTAS call blocked - exploit attempt? [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct) errinjct: Could not open RTAS error injection facility errinjct: librtas: open: Unexpected I/O error The entry for ibm,open-errinjct in rtas_filter array has a typo where the "j" is omitted in the rtas call name. After fixing this typo the errinjct tool functions again as expected. [root@ltcalpine2-lp5 linux]# errinjct open RTAS error injection facility open, token = 1 Fixes: bd59380c ("powerpc/rtas: Restrict RTAS requests from userspace") Cc: stable@vger.kernel.org Signed-off-by: NTyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201208195434.8289-1-tyreld@linux.ibm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mathieu Desnoyers 提交于
stable inclusion from stable-5.10.4 commit a4af71ae5a6becd5ab9a84314407eb9fed349133 bugzilla: 46903 -------------------------------- commit d85be8a4 upstream. The placeholder for instruction selection should use the second argument's operand, which is %1, not %0. This could generate incorrect assembly code if the memory addressing of operand %0 is a different form from that of operand %1. Also remove the %Un placeholder because having %Un placeholders for two operands which are based on the same local var (ptep) doesn't make much sense. By the way, it doesn't change the current behaviour because "<>" constraint is missing for the associated "=m". [chleroy: revised commit log iaw segher's comments and removed %U0] Fixes: 9bf2b5cd ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support") Cc: <stable@vger.kernel.org> # v2.6.28+ Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Acked-by: NSegher Boessenkool <segher@kernel.crashing.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/96354bd77977a6a933fe9020da57629007fdb920.1603358942.git.christophe.leroy@csgroup.euSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-