Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
11 个月 前同步成功

通知 150
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 22 5月, 2009 1 次提交
  3. 08 4月, 2009 1 次提交
  5. 05 3月, 2009 1 次提交
  7. 18 2月, 2009 2 次提交
  9. 29 1月, 2009 2 次提交
  11. 08 1月, 2009 1 次提交
  13. 04 1月, 2009 1 次提交
  15. 31 12月, 2008 1 次提交
    • E
      x86: disable VMX on all CPUs on reboot · d176720d
      由 Eduardo Habkost 提交于 
      On emergency_restart, we may need to use an NMI to disable virtualization
on all CPUs. We do that using nmi_shootdown_cpus() if VMX is enabled.

Note: With this patch, we will run the NMI stuff only when the CPU where
emergency_restart() was called has VMX enabled. This should work on most
cases because KVM enables VMX on all CPUs, but we may miss the small
window where KVM is doing that. Also, I don't know if all code using
VMX out there always enable VMX on all CPUs like KVM does. We have two
other alternatives for that:

a) Have an API that all code that enables VMX on any CPU should use
   to tell the kernel core that it is going to enable VMX on the CPUs.
b) Always call nmi_shootdown_cpus() if the CPU supports VMX. This is
   a bit intrusive and more risky, as it would run nmi_shootdown_cpus()
   on emergency_reboot() even on systems where virtualization is never
   enabled.

Finding a proper point to hook the nmi_shootdown_cpus() call isn't
trivial, as the non-emergency machine_restart() (that doesn't need the
NMI tricks) uses machine_emergency_restart() directly.

The solution to make this work without adding a new function or argument
to machine_ops was setting a 'reboot_emergency' flag that tells if
native_machine_emergency_restart() needs to do the virt cleanup or not.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
      d176720d
  17. 30 12月, 2008 1 次提交
  19. 27 12月, 2008 1 次提交
  21. 24 11月, 2008 1 次提交
    • H
      x86: drop REBOOT_CF9_COND from reboot fallback chain · b47b9288
      由 H. Peter Anvin 提交于 
      Impact: Reverts sequence of reboot fallbacks

Checkin 14d7ca5c changed the default
reboot method to "pci", a.k.a. port CF9.  Unfortunately this has been
shown to cause lockups on at least two systems for which REBOOT_KBD
worked, both Thinkpads with Intel chipsets.  Checkin
3889d0ce reverted the default, but did
not revert the fallback chain.  This checkin reverts the fallback
chain; port CF9 is now only done by explicit "reboot=pci" or a future
potential DMI key.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      b47b9288
  23. 23 11月, 2008 1 次提交
    • H
      x86: revert default reboot method to REBOOT_KBD · 3889d0ce
      由 H. Peter Anvin 提交于 
      Impact: Reverts default reboot method.

Checkin 14d7ca5c changed the default
reboot method to "pci", a.k.a. port CF9.  Unfortunately this has been
shown to cause lockups on at least two systems for which REBOOT_KBD
worked, both Thinkpads with Intel chipsets.  This reverts the default
to REBOOT_KBD, while leaving the option to have "reboot=pci" specified
explicitly or via a DMI match.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      3889d0ce
  25. 19 11月, 2008 1 次提交
  27. 13 11月, 2008 3 次提交
  29. 12 11月, 2008 1 次提交
    • H
      x86: attempt reboot via port CF9 if we have standard PCI ports · 14d7ca5c
      由 H. Peter Anvin 提交于 
      Impact: Changes reboot behavior.

If port CF9 seems to be safe to touch, attempt it before trying the
keyboard controller.  Port CF9 is not available on all chipsets (a
significant but decreasing number of modern chipsets don't implement
it), but port CF9 itself should in general be safe to poke (no ill
effects if unimplemented) on any system which has PCI Configuration
Method #1 or #2, as it falls inside the PCI configuration port range
in both cases.  No chipset without PCI is known to have port CF9,
either, although an explicit "pci=bios" would mean we miss this and
therefore don't use port CF9.  An explicit "reboot=pci" can be used to
force the use of port CF9.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      14d7ca5c
  31. 11 11月, 2008 1 次提交
    • I
      x86: call machine_shutdown and stop all CPUs in native_machine_halt · d3ec5cae
      由 Ivan Vecera 提交于 
      Impact: really halt all CPUs on halt

Function machine_halt (resp. native_machine_halt) is empty for x86
architectures. When command 'halt -f' is invoked, the message "System
halted." is displayed but this is not really true because all CPUs are
still running.

There are also similar inconsistencies for other arches (some uses
power-off for halt or forever-loop with IRQs enabled/disabled).

IMO there should be used the same approach for all architectures OR
what does the message "System halted" really mean?

This patch fixes it for x86.
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3ec5cae
  33. 06 11月, 2008 1 次提交
  35. 25 8月, 2008 1 次提交
    • A
      x86: default to reboot via ACPI · c7ffa6c2
      由 Avi Kivity 提交于 
      Triple-fault and keyboard reset may assert INIT instead of RESET; however
INIT is blocked when Intel VT is enabled.  This leads to a partially reset
machine when invoking emergency_restart via sysrq-b: the processor is still
working but other parts of the system are dead.

Default to rebooting via ACPI, which correctly asserts RESET and reboots the
machine.

This is safe since we will fall back to keyboard reset and triple fault if
acpi is not enabled or if the reset is not successful.
Signed-off-by: NAvi Kivity <avi@qumranet.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7ffa6c2
  37. 26 7月, 2008 1 次提交
  39. 19 7月, 2008 1 次提交
    • M
      cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr · 65c01184
      由 Mike Travis 提交于 
        * This patch replaces the dangerous lvalue version of cpumask_of_cpu
    with new cpumask_of_cpu_ptr macros.  These are patterned after the
    node_to_cpumask_ptr macros.

    In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
    the cpumask_of_cpu_map[cpu] entry is used.  The cpumask_of_cpu_map
    is provided when there is a large NR_CPUS count, reducing
    greatly the amount of code generated and stack space used for
    cpumask_of_cpu().  The pointer to the cpumask_t value is needed for
    calling set_cpus_allowed_ptr() to reduce the amount of stack space
    needed to pass the cpumask_t value.

    If there isn't a cpumask_of_cpu_map[], then a temporary variable is
    declared and filled in with value from cpumask_of_cpu(cpu) as well as
    a pointer variable pointing to this temporary variable.  Afterwards,
    the pointer is used to reference the cpumask value.  The compiler
    will optimize out the extra dereference through the pointer as well
    as the stack space used for the pointer, resulting in identical code.

    A good example of the orthogonal usages is in net/sunrpc/svc.c:

	case SVC_POOL_PERCPU:
	{
		unsigned int cpu = m->pool_to[pidx];
		cpumask_of_cpu_ptr(cpumask, cpu);

		*oldmask = current->cpus_allowed;
		set_cpus_allowed_ptr(current, cpumask);
		return 1;
	}
	case SVC_POOL_PERNODE:
	{
		unsigned int node = m->pool_to[pidx];
		node_to_cpumask_ptr(nodecpumask, node);

		*oldmask = current->cpus_allowed;
		set_cpus_allowed_ptr(current, nodecpumask);
		return 1;
	}
Signed-off-by: NMike Travis <travis@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      65c01184
  41. 17 7月, 2008 1 次提交
  43. 25 5月, 2008 1 次提交
  45. 05 5月, 2008 1 次提交
  47. 01 5月, 2008 1 次提交
  49. 27 4月, 2008 2 次提交
  51. 25 4月, 2008 1 次提交
    • J
      x86: unify KERNEL_PGD_PTRS · 68db065c
      由 Jeremy Fitzhardinge 提交于 
      Make KERNEL_PGD_PTRS common, as previously it was only being defined
for 32-bit.

There are a couple of follow-on changes from this:
 - KERNEL_PGD_PTRS was being defined in terms of USER_PGD_PTRS.  The
   definition of USER_PGD_PTRS doesn't really make much sense on x86-64,
   since it can have two different user address-space configurations.
   I renamed USER_PGD_PTRS to KERNEL_PGD_BOUNDARY, which is meaningful
   for all of 32/32, 32/64 and 64/64 process configurations.

 - USER_PTRS_PER_PGD was also defined and was being used for similar
   purposes.  Converting its users to KERNEL_PGD_BOUNDARY left it
   completely unused, and so I removed it.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Zach Amsden <zach@vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      68db065c
  53. 20 4月, 2008 1 次提交
    • M
      x86: use new set_cpus_allowed_ptr function · fc0e4748
      由 Mike Travis 提交于 
        * Use new set_cpus_allowed_ptr() function added by previous patch,
    which instead of passing the "newly allowed cpus" cpumask_t arg
    by value,  pass it by pointer:

    -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
    +int set_cpus_allowed_ptr(struct task_struct *p, const cpumask_t *new_mask)

  * Cleanup uses of CPU_MASK_ALL.

  * Collapse other NR_CPUS changes to arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
    Use pointers to cpumask_t arguments whenever possible.

Depends on:
	[sched-devel]: sched: add new set_cpus_allowed_ptr function

Cc: Len Brown <len.brown@intel.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: NMike Travis <travis@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc0e4748
  55. 17 4月, 2008 2 次提交
  57. 22 3月, 2008 2 次提交
  59. 07 3月, 2008 1 次提交
  61. 13 2月, 2008 1 次提交
  63. 30 1月, 2008 2 次提交