Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 8月, 2017 5 次提交
  3. 09 8月, 2017 7 次提交
  5. 08 8月, 2017 5 次提交
    • P
      MIPS: Set ISA bit in entry-y for microMIPS kernels · 5fc9484f
      由 Paul Burton 提交于 
      When building a kernel for the microMIPS ISA, ensure that the ISA bit
(ie. bit 0) in the entry address is set. Otherwise we may include an
entry address in images which bootloaders will jump to as MIPS32 code.

I originally tried using "objdump -f" to obtain the entry address, which
works for microMIPS but it always outputs a 32 bit address for a 32 bit
ELF whilst nm will sign extend to 64 bit. That matters for systems where
we might want to run a MIPS32 kernel on a MIPS64 CPU & load it with a
MIPS64 bootloader, which would then jump to a non-canonical
(non-sign-extended) address.

This works in all cases as it only changes the behaviour for microMIPS
kernels, but isn't the prettiest solution. A possible alternative would
be to write a custom tool to just extract, sign extend & print the entry
point of an ELF executable. I'm open to feedback if that would be
preferred.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16950/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5fc9484f
    • P
      MIPS: Prevent building MT support for microMIPS kernels · 527f1028
      由 Paul Burton 提交于 
      We don't currently support the MT ASE for microMIPS kernels, and there
are no CPUs currently in existence that use both. They can however both
be enabled in Kconfig, resulting in build failures such as:

  AS      arch/mips/kernel/cps-vec.o
arch/mips/kernel/cps-vec.S: Assembler messages:
arch/mips/kernel/cps-vec.S:242: Warning: the 32-bit microMIPS architecture does not support the `mt' extension
arch/mips/kernel/cps-vec.S:276: Error: unrecognized opcode `mttc0 $13,$2,2'
arch/mips/kernel/cps-vec.S:282: Error: unrecognized opcode `mttc0 $8,$1,2'
arch/mips/kernel/cps-vec.S:285: Error: unrecognized opcode `mttc0 $0,$2,1'
...

Fix this by preventing MT from being enabled when targeting microMIPS.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16951/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      527f1028
    • G
      powerpc/powernv/idle: Disable LOSE_FULL_CONTEXT states when stop-api fails · 785a12af
      由 Gautham R. Shenoy 提交于 
      Currently, we use the opal call opal_slw_set_reg() to inform the
Sleep-Winkle Engine (SLW) to restore the contents of some of the
Hypervisor state on wakeup from deep idle states that lose full
hypervisor context (characterized by the flag
OPAL_PM_LOSE_FULL_CONTEXT).

However, the current code has a bug in that if opal_slw_set_reg()
fails, we don't disable the use of these deep states (winkle on
POWER8, stop4 onwards on POWER9).

This patch fixes this bug by ensuring that if programing the
sleep-winkle engine to restore the hypervisor states in
pnv_save_sprs_for_deep_states() fails, then we exclude such states by
clearing the OPAL_PM_LOSE_FULL_CONTEXT flag from
supported_cpuidle_states. As a result POWER8 will be prevented from
using winkle for CPU-Hotplug, and POWER9 will put the offlined CPUs to
the default stop state when available.

Further, we ensure in the initialization of the cpuidle-powernv driver
to only include those states whose flags are present in
supported_cpuidle_states, thereby skipping OPAL_PM_LOSE_FULL_CONTEXT
states when they have been disabled due to stop-api failure.

Fixes: 1e1601b3 ("powerpc/powernv/idle: Restore SPRs for deep idle
states via stop API.")
Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      785a12af
    • M
      MIPS: PCI: Fix smp_processor_id() in preemptible · 73530266
      由 Matt Redfearn 提交于 
      Commit 1c3c5eab ("sched/core: Enable might_sleep() and
smp_processor_id() checks early") enables checks for might_sleep() and
smp_processor_id() being used in preemptible code earlier in the boot
than before. This results in a new BUG from
pcibios_set_cache_line_size().

BUG: using smp_processor_id() in preemptible [00000000] code:
swapper/0/1 caller is pcibios_set_cache_line_size+0x10/0x70
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc1-00007-g3ce3e4ba4275 #615
Stack: 0000000000000000 ffffffff81189694 0000000000000000 ffffffff81822318
       000000000000004e 0000000000000001 800000000e20bd08 20c49ba5e3540000
       0000000000000000 0000000000000000 ffffffff818d0000 0000000000000000
       0000000000000000 ffffffff81189328 ffffffff818ce692 0000000000000000
       0000000000000000 ffffffff81189bc8 ffffffff818d0000 0000000000000000
       ffffffff81828907 ffffffff81769970 800000020ec78d80 ffffffff818c7b48
       0000000000000001 0000000000000001 ffffffff818652b0 ffffffff81896268
       ffffffff818c0000 800000020ec7fb40 800000020ec7fc58 ffffffff81684cac
       0000000000000000 ffffffff8118ab50 0000000000000030 ffffffff81769970
       0000000000000001 ffffffff81122a58 0000000000000000 0000000000000000 ...
Call Trace:
[<ffffffff81122a58>] show_stack+0x90/0xb0
[<ffffffff81684cac>] dump_stack+0xac/0xf0
[<ffffffff813f7050>] check_preemption_disabled+0x120/0x128
[<ffffffff818855e8>] pcibios_set_cache_line_size+0x10/0x70
[<ffffffff81100578>] do_one_initcall+0x48/0x140
[<ffffffff81865dc4>] kernel_init_freeable+0x194/0x24c
[<ffffffff8169c534>] kernel_init+0x14/0x118
[<ffffffff8111ca84>] ret_from_kernel_thread+0x14/0x1c

Fix this by using the cpu_*cache_line_size() macros instead. These
macros are the "proper" way to determine the CPU cache sizes.
This makes use of the newly added cpu_tcache_line_size.

Fixes: 1c3c5eab ("sched/core: Enable might_sleep() and smp_processor_id() checks early")
Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Suggested-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      73530266
    • M
      MIPS: Introduce cpu_tcache_line_size · 21da5332
      由 Matt Redfearn 提交于 
      There exist macros to return the cache line size of the L1 dcache and L2
scache but there is currently no macro for the L3 tcache. Add this macro
which will be used by the following patch "MIPS: PCI: Fix
smp_processor_id() in preemptible"
Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Cc: Maciej W. Rozycki <macro@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16871/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      21da5332
  7. 07 8月, 2017 9 次提交
  9. 05 8月, 2017 6 次提交
  11. 04 8月, 2017 5 次提交
  13. 03 8月, 2017 3 次提交
    • W
      KVM: nVMX: Fix interrupt window request with "Acknowledge interrupt on exit" · 6550c4df
      由 Wanpeng Li 提交于 
      ------------[ cut here ]------------
 WARNING: CPU: 5 PID: 2288 at arch/x86/kvm/vmx.c:11124 nested_vmx_vmexit+0xd64/0xd70 [kvm_intel]
 CPU: 5 PID: 2288 Comm: qemu-system-x86 Not tainted 4.13.0-rc2+ #7
 RIP: 0010:nested_vmx_vmexit+0xd64/0xd70 [kvm_intel]
Call Trace:
  vmx_check_nested_events+0x131/0x1f0 [kvm_intel]
  ? vmx_check_nested_events+0x131/0x1f0 [kvm_intel]
  kvm_arch_vcpu_ioctl_run+0x5dd/0x1be0 [kvm]
  ? vmx_vcpu_load+0x1be/0x220 [kvm_intel]
  ? kvm_arch_vcpu_load+0x62/0x230 [kvm]
  kvm_vcpu_ioctl+0x340/0x700 [kvm]
  ? kvm_vcpu_ioctl+0x340/0x700 [kvm]
  ? __fget+0xfc/0x210
  do_vfs_ioctl+0xa4/0x6a0
  ? __fget+0x11d/0x210
  SyS_ioctl+0x79/0x90
  do_syscall_64+0x8f/0x750
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  entry_SYSCALL64_slow_path+0x25/0x25

This can be reproduced by booting L1 guest w/ 'noapic' grub parameter, which
means that tells the kernel to not make use of any IOAPICs that may be present
in the system.

Actually external_intr variable in nested_vmx_vmexit() is the req_int_win
variable passed from vcpu_enter_guest() which means that the L0's userspace
requests an irq window. I observed the scenario (!kvm_cpu_has_interrupt(vcpu) &&
L0's userspace reqeusts an irq window) is true, so there is no interrupt which
L1 requires to inject to L2, we should not attempt to emualte "Acknowledge
interrupt on exit" for the irq window requirement in this scenario.

This patch fixes it by not attempt to emulate "Acknowledge interrupt on exit"
if there is no L1 requirement to inject an interrupt to L2.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
[Added code comment to make it obvious that the behavior is not correct.
 We should do a userspace exit with open interrupt window instead of the
 nested VM exit.  This patch still improves the behavior, so it was
 accepted as a (temporary) workaround.]
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      6550c4df
    • D
      KVM: nVMX: mark vmcs12 pages dirty on L2 exit · c9f04407
      由 David Matlack 提交于 
      The host physical addresses of L1's Virtual APIC Page and Posted
Interrupt descriptor are loaded into the VMCS02. The CPU may write
to these pages via their host physical address while L2 is running,
bypassing address-translation-based dirty tracking (e.g. EPT write
protection). Mark them dirty on every exit from L2 to prevent them
from getting out of sync with dirty tracking.

Also mark the virtual APIC page and the posted interrupt descriptor
dirty when KVM is virtualizing posted interrupt processing.
Signed-off-by: NDavid Matlack <dmatlack@google.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      c9f04407
    • D
      kvm: nVMX: don't flush VMCS12 during VMXOFF or VCPU teardown · 8ca44e88
      由 David Matlack 提交于 
      According to the Intel SDM, software cannot rely on the current VMCS to be
coherent after a VMXOFF or shutdown. So this is a valid way to handle VMCS12
flushes.

24.11.1 Software Use of Virtual-Machine Control Structures
...
  If a logical processor leaves VMX operation, any VMCSs active on
  that logical processor may be corrupted (see below). To prevent
  such corruption of a VMCS that may be used either after a return
  to VMX operation or on another logical processor, software should
  execute VMCLEAR for that VMCS before executing the VMXOFF instruction
  or removing power from the processor (e.g., as part of a transition
  to the S3 and S4 power states).
...

This fixes a "suspicious rcu_dereference_check() usage!" warning during
kvm_vm_release() because nested_release_vmcs12() calls
kvm_vcpu_write_guest_page() without holding kvm->srcu.
Signed-off-by: NDavid Matlack <dmatlack@google.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      8ca44e88