BMC/Intel-BMC/linux.git/arch/mips/kvm, branch dev-5.4

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2019-08-09T22:46:29+00:00

Pull kvm fixes from Paolo Bonzini: "Bugfixes (arm and x86) and cleanups" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: selftests: kvm: Adding config fragments KVM: selftests: Update gitignore file for latest changes kvm: remove unnecessary PageReserved check KVM: arm/arm64: vgic: Reevaluate level sensitive interrupts on enable KVM: arm: Don't write junk to CP15 registers on reset KVM: arm64: Don't write junk to sysregs on reset KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block x86: kvm: remove useless calls to kvm_para_available KVM: no need to check return value of debugfs_create functions KVM: remove kvm_arch_has_vcpu_debugfs() KVM: Fix leak vCPU's VMCS value into other pCPU KVM: Check preempted_in_kernel for involuntary preemption KVM: LAPIC: Don't need to wakeup vCPU twice afer timer fire arm64: KVM: hyp: debug-sr: Mark expected switch fall-through KVM: arm64: Update kvm_arm_exception_class and esr_class_str for new EC KVM: arm: vgic-v3: Mark expected switch fall-through arm64: KVM: regmap: Fix unexpected switch fall-through KVM: arm/arm64: Introduce kvm_pmu_vcpu_init() to setup PMU counter index

Merge tag 'mips_fixes_5.3_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux

2019-08-06T21:01:08+00:00

Pull MIPS fixes from Paul Burton: "A few MIPS fixes for 5.3: - Various switch fall through annotations to fixup warnings & errors resulting from -Wimplicit-fallthrough. - A fix for systems (at least jazz) using an i8253 PIT as clocksource when it's not suitably configured. - Set struct cacheinfo's cpu_map_populated field to true, indicating that we filled in cache info detected from cop0 registers & avoiding complaints about that info being (intentionally) missing in devicetree" * tag 'mips_fixes_5.3_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: BCM63XX: Mark expected switch fall-through MIPS: OProfile: Mark expected switch fall-throughs MIPS: Annotate fall-through in Cavium Octeon code MIPS: Annotate fall-through in kvm/emulate.c mips: fix cacheinfo MIPS: kernel: only use i8253 clocksource with periodic clockevent

KVM: remove kvm_arch_has_vcpu_debugfs()

2019-08-05T10:55:48+00:00

There is no need for this function as all arches have to implement kvm_arch_create_vcpu_debugfs() no matter what. A #define symbol let us actually simplify the code. Signed-off-by: Paolo Bonzini

MIPS: Annotate fall-through in kvm/emulate.c

2019-07-18T21:41:04+00:00

kvm_compute_return_epc contains a switch statement with an intentional fall-through from a case handling jal (jump and link) instructions to one handling j (jump) instructions. With -Wimplicit-fallthrough this triggers a compile error (due to -Werror being enabled for arch/mips). This can be reproduced using malta_kvm_defconfig. Fix this by annotating the intentional fall-through. Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org

KVM: Directly return result from kvm_arch_check_processor_compat()

2019-06-04T17:27:32+00:00

Add a wrapper to invoke kvm_arch_check_processor_compat() so that the boilerplate ugliness of checking virtualization support on all CPUs is hidden from the arch specific code. x86's implementation in particular is quite heinous, as it unnecessarily propagates the out-param pattern into kvm_x86_ops. While the x86 specific issue could be resolved solely by changing kvm_x86_ops, make the change for all architectures as returning a value directly is prettier and technically more robust, e.g. s390 doesn't set the out param, which could lead to subtle breakage in the (highly unlikely) scenario where the out-param was not pre-initialized by the caller. Opportunistically annotate svm_check_processor_compat() with __init. Signed-off-by: Sean Christopherson Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini

KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID

2019-05-28T13:52:19+00:00

KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using the vcpu_id as an index into the SCA structures that are defined by the hardware (see e.g. the sca_add_vcpu() function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use. Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as for KVM_CAP_MAX_VCPUS. This problem has been discovered with the kvm_create_max_vcpus selftest. With this change applied, the selftest now passes on s390x, too. Reviewed-by: Andrew Jones Reviewed-by: Cornelia Huck Reviewed-by: David Hildenbrand Signed-off-by: Thomas Huth Message-Id: <20190523164309.13345-9-thuth@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger

Merge tag 'mips_5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux

2019-05-08T23:41:47+00:00

Pull MIPS updates from Paul Burton: - A set of memblock initialization improvements thanks to Serge Semin, tidying up after our conversion from bootmem to memblock back in v4.20. - Our eBPF JIT the previously supported only MIPS64r2 through MIPS64r5 is improved to also support MIPS64r6. Support for MIPS32 systems is introduced, with the caveat that it only works for programs that don't use 64 bit registers or operations - those will bail out & need to be interpreted. - Improvements to the allocation & configuration of our exception vector that should fix issues seen on some platforms using recent versions of U-Boot. - Some minor improvements to code generated for jump labels, along with enabling them by default for generic kernels. * tag 'mips_5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (27 commits) mips: Manually call fdt_init_reserved_mem() method mips: Make sure dt memory regions are valid mips: Perform early low memory test mips: Dump memblock regions for debugging mips: Add reserve-nomap memory type support mips: Use memblock to reserve the __nosave memory range mips: Discard post-CMA-init foreach loop mips: Reserve memory for the kernel image resources MIPS: Remove duplicate EBase configuration MIPS: Sync icache for whole exception vector MIPS: Always allocate exception vector for MIPSr2+ MIPS: Use memblock_phys_alloc() for exception vector mips: Combine memblock init and memory reservation loops mips: Discard rudiments from bootmem_init mips: Make sure kernel .bss exists in boot mem pool mips: vdso: drop unnecessary cc-ldoption Revert "MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices" MIPS: generic: Enable CONFIG_JUMP_LABEL MIPS: jump_label: Use compact branches for >= r6 MIPS: jump_label: Remove redundant nops ...

Make anon_inodes unconditional

2019-04-19T12:03:11+00:00

Make the anon_inodes facility unconditional so that it can be used by core VFS code and pidfd code. Signed-off-by: David Howells Signed-off-by: Al Viro [christian@brauner.io: adapt commit message to mention pidfds] Signed-off-by: Christian Brauner

MIPS: KVM: Use prandom_u32_max() to generate tlbwr index

2019-03-25T21:02:12+00:00

Emulation of the tlbwr instruction, which writes a TLB entry to a random index in the TLB, currently uses get_random_bytes() to generate a 4 byte random number which we then mask to form the index. This is overkill in a couple of ways: - We don't need 4 bytes here since we mask the value to form a 6 bit number anyway, so we waste /dev/random entropy generating 3 random bytes that are unused. - We don't need crypto-grade randomness here - the architecture spec allows implementations to use any algorithm & merely encourages that some pseudo-randomness be used rather than a simple counter. The fast prandom_u32() function fits that criteria well. So rather than using get_random_bytes() & consuming /dev/random entropy, switch to using the faster prandom_u32_max() which provides what we need here whilst also performing the masking/modulo for us. Signed-off-by: Paul Burton Reported-by: George Spelvin Cc: James Hogan Cc: linux-mips@vger.kernel.org

MIPS: MemoryMapID (MMID) Support

2019-02-04T18:56:41+00:00

Introduce support for using MemoryMapIDs (MMIDs) as an alternative to Address Space IDs (ASIDs). The major difference between the two is that MMIDs are global - ie. an MMID uniquely identifies an address space across all coherent CPUs. In contrast ASIDs are non-global per-CPU IDs, wherein each address space is allocated a separate ASID for each CPU upon which it is used. This global namespace allows a new GINVT instruction be used to globally invalidate TLB entries associated with a particular MMID across all coherent CPUs in the system, removing the need for IPIs to invalidate entries with separate ASIDs on each CPU. The allocation scheme used here is largely borrowed from arm64 (see arch/arm64/mm/context.c). In essence we maintain a bitmap to track available MMIDs, and MMIDs in active use at the time of a rollover to a new MMID version are preserved in the new version. The allocation scheme requires efficient 64 bit atomics in order to perform reasonably, so this support depends upon CONFIG_GENERIC_ATOMIC64=n (ie. currently it will only be included in MIPS64 kernels). The first, and currently only, available CPU with support for MMIDs is the MIPS I6500. This CPU supports 16 bit MMIDs, and so for now we cap our MMIDs to 16 bits wide in order to prevent the bitmap growing to absurd sizes if any future CPU does implement 32 bit MMIDs as the architecture manuals suggest is recommended. When MMIDs are in use we also make use of GINVT instruction which is available due to the global nature of MMIDs. By executing a sequence of GINVT & SYNC 0x14 instructions we can avoid the overhead of an IPI to each remote CPU in many cases. One complication is that GINVT will invalidate wired entries (in all cases apart from type 0, which targets the entire TLB). In order to avoid GINVT invalidating any wired TLB entries we set up, we make sure to create those entries using a reserved MMID (0) that we never associate with any address space. Also of note is that KVM will require further work in order to support MMIDs & GINVT, since KVM is involved in allocating IDs for guests & in configuring the MMU. That work is not part of this patch, so for now when MMIDs are in use KVM is disabled. Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org