x86: vmclear vmcss on all cpus when doing kdump if necessary
Subsystems (5)
v8 cover x86: vmclear vmcss on all cpus when doing kdump if necessary
Currently, kdump just makes all the logical processors leave VMX operation by executing VMXOFF instruction, so any VMCSs active on the logical processors may be corrupted. But, sometimes, we need the VMCSs to debug guest images contained in the host vmcore. To prevent the corruption, we should VMCLEAR the VMCSs before executing the VMXOFF instruction.
The patch set provides a way to VMCLEAR vmcss related to guests on all cpus before executing the VMXOFF when doing kdump. This is used to ensure the VMCSs in the vmcore updated and non-corrupted.
Changelog from v7 to v8:
1. KEXEC: regression for using name crash_notifier_list and remove comments related to KVM
and just call function atomic_notifier_call_chain directly.
Changelog from v6 to v7:
1. KVM-INTEL: in hardware_disable, we needn't disable the vmclear, so remove it.
Changelog from v5 to v6:
1. KEXEC: the atomic notifier list renamed:
crash_notifier_list --> vmclear_notifier_list
2. KVM-INTEL: provide empty functions if CONFIG_KEXEC is not defined and remove unnecessary #ifdef's.
Changelog from v4 to v5:
1. use an atomic notifier instead of function call, so have all the vmclear codes in vmx.c.
Changelog from v3 to v4:
1. add a new percpu variable vmclear_skipped to skip vmclear in kdump in some conditions.
Changelog from v2 to v3:
1. remove unnecessary conditions in function cpu_emergency_clear_loaded_vmcss as Marcelo suggested.
Changelog from v1 to v2:
1. remove the sysctl and clear VMCSs unconditionally.
Zhang Yanfei (2):
x86/kexec: add a new atomic notifier list for kdump
KVM-INTEL: add a notifier and a bitmap to support VMCLEAR in kdump
arch/x86/include/asm/kexec.h | 2 + arch/x86/kernel/crash.c | 9 +++++ arch/x86/kvm/vmx.c | 70 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 81 insertions(+), 0 deletions(-)
PATCH v8 1/2 x86/kexec: add a new atomic notifier list for kdump
This patch adds an atomic notifier list named crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.
--- arch/x86/include/asm/kexec.h | 2 ++ arch/x86/kernel/crash.c | 9 +++++++++ 2 files changed, 11 insertions(+), 0 deletions(-)
arch/x86/include/asm/kexec.h +2 -0
@@ -163,6 +163,8 @@ struct kimage_arch { };#endif +extern struct atomic_notifier_head crash_notifier_list; +#endif /* __ASSEMBLY__ */ #endif /* _ASM_X86_KEXEC_H */
arch/x86/kernel/crash.c +9 -0
@@ -16,6 +16,8 @@#include <linux/delay.h> #include <linux/elf.h> #include <linux/elfcore.h> +#include <linux/module.h> +#include <linux/notifier.h> #include <asm/processor.h> #include <asm/hardirq.h>
@@ -30,6 +32,9 @@int in_crash_kexec; +ATOMIC_NOTIFIER_HEAD (crash_notifier_list); +EXPORT_SYMBOL_GPL (crash_notifier_list); +#if defined(CONFIG_SMP ) && defined(CONFIG_X86_LOCAL_APIC )static void kdump_nmi_callback (int cpu,struct pt_regs *regs)
@@ -46,6 +51,8 @@ static void kdump_nmi_callback(int cpu, struct pt_regs *regs)#endif crash_save_cpu (regs, cpu); +atomic_notifier_call_chain (&crash_notifier_list,0 ,NULL ); +/* Disable VMX or SVM if needed. * * We need to disable virtualization on all CPUs.
@@ -88,6 +95,8 @@ void native_machine_crash_shutdown(struct pt_regs *regs)kdump_nmi_shootdown_cpus (); +atomic_notifier_call_chain (&crash_notifier_list,0 ,NULL ); +/* Booting kdump kernel with VMX or SVM enabled won't work, * because (among other limitations) we can't disable paging * with the virt flags.
Signature · 1 line
1.7.1
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 4 lines · Zhang Yanfei
This patch adds an atomic notifier list named
crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.
crash_notifier_list ick gag please no. Effectively this makes the kexec on panic code path undebuggable.
Instead we need to use direct function calls to whatever you are doing.
If a direct function call is too complex then the piece of code you want to call is almost certainly too complex to be calling on a code path like this.
Eric
Quoted 60 lines
Signed-off-by Zhang Yanfei <[email protected]>--- arch/x86/include/asm/kexec.h | 2 ++ arch/x86/kernel/crash.c | 9 +++++++++ 2 files changed, 11 insertions(+), 0 deletions(-)arch/x86/include/asm/kexec.h +2
-0@@ -163,6 +163,8 @@ struct kimage_arch { };#endif +extern struct atomic_notifier_head crash_notifier_list; +#endif /* __ASSEMBLY__ */ #endif /* _ASM_X86_KEXEC_H */ arch/x86/kernel/crash.c +9
-0@@ -16,6 +16,8 @@#include <linux/delay.h> #include <linux/elf.h> #include <linux/elfcore.h> +#include <linux/module.h> +#include <linux/notifier.h> #include <asm/processor.h> #include <asm/hardirq.h> @@ -30,6 +32,9 @@int in_crash_kexec; +ATOMIC_NOTIFIER_HEAD (crash_notifier_list); +EXPORT_SYMBOL_GPL (crash_notifier_list); +#if defined(CONFIG_SMP ) && defined(CONFIG_X86_LOCAL_APIC )static void kdump_nmi_callback (int cpu,struct pt_regs *regs)@@ -46,6 +51,8 @@ static void kdump_nmi_callback(int cpu, struct pt_regs *regs)#endif crash_save_cpu (regs, cpu); +atomic_notifier_call_chain (&crash_notifier_list,0 ,NULL ); +/* Disable VMX or SVM if needed. * * We need to disable virtualization on all CPUs. @@ -88,6 +95,8 @@ void native_machine_crash_shutdown(struct pt_regs *regs)kdump_nmi_shootdown_cpus (); +atomic_notifier_call_chain (&crash_notifier_list,0 ,NULL ); +/* Booting kdump kernel with VMX or SVM enabled won't work, * because (among other limitations) we can't disable paging * with the virt flags.
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 7 lines · Eric W. Biederman
Quoted 4 lines · Zhang Yanfei
This patch adds an atomic notifier list named
crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.
Quoted 5 lines
crash_notifier_listick gag please no. Effectively this makes the kexec on panic code path undebuggable.Instead we need to use direct function calls to whatever you are doing.
The code walks linked list in kvm-intel module and calls vmclear on whatever it finds there. Since the function have to resides in kvm-intel module it cannot be called directly. Is callback pointer that is set by kvm-intel more acceptable?
Quoted 59 lines
If a direct function call is too complex then the piece of code you want to call is almost certainly too complex to be calling on a code path like this.
Eric
Quoted 53 lines
Signed-off-by Zhang Yanfei <[email protected]>--- arch/x86/include/asm/kexec.h | 2 ++ arch/x86/kernel/crash.c | 9 +++++++++ 2 files changed, 11 insertions(+), 0 deletions(-)arch/x86/include/asm/kexec.h +2
-0@@ -163,6 +163,8 @@ struct kimage_arch { };#endif +extern struct atomic_notifier_head crash_notifier_list; +#endif /* __ASSEMBLY__ */ #endif /* _ASM_X86_KEXEC_H */ arch/x86/kernel/crash.c +7
-0@@ -16,6 +16,8 @@#include <linux/delay.h> #include <linux/elf.h> #include <linux/elfcore.h> +#include <linux/module.h> +#include <linux/notifier.h> #include <asm/processor.h> #include <asm/hardirq.h> @@ -30,6 +32,9 @@int in_crash_kexec; +ATOMIC_NOTIFIER_HEAD (crash_notifier_list); +EXPORT_SYMBOL_GPL (crash_notifier_list); +#if defined(CONFIG_SMP ) && defined(CONFIG_X86_LOCAL_APIC )static void kdump_nmi_callback (int cpu,struct pt_regs *regs)@@ -46,6 +51,8 @@ static void kdump_nmi_callback(int cpu, struct pt_regs *regs)#endif crash_save_cpu (regs, cpu); +atomic_notifier_call_chain (&crash_notifier_list,0 ,NULL ); +/* Disable VMX or SVM if needed. * * We need to disable virtualization on all CPUs. @@ -88,6 +95,8 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
Quoted 7 lines
arch/x86/kernel/crash.c void native_machine_crash_shutdown(struct pt_regs *regs) · line 102
Quoted 7 lines
arch/x86/kernel/crash.c +2
-0kdump_nmi_shootdown_cpus (); +atomic_notifier_call_chain (&crash_notifier_list,0 ,NULL ); +/* Booting kdump kernel with VMX or SVM enabled won't work, * because (among other limitations) we can't disable paging * with the virt flags.
--
Gleb.
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 11 lines · Gleb Natapov
Quoted 10 lines · Eric W. Biederman
Quoted 4 lines · Zhang Yanfei
This patch adds an atomic notifier list named
crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.
crash_notifier_listick gag please no. Effectively this makes the kexec on panic code path undebuggable.
Quoted 6 lines
Quoted 2 lines
Instead we need to use direct function calls to whatever you are doing.
The code walks linked list in kvm-intel module and calls vmclear on whatever it finds there. Since the function have to resides in kvm-intel module it cannot be called directly. Is callback pointer that is set by kvm-intel more acceptable?
Yes a specific callback function is more acceptable. Looking a little deeper vmclear_local_loaded_vmcss is not particularly acceptable. It is doing a lot of work that is unnecessary to save the virtual registers on the kexec on panic path.
In fact I wonder if it might not just be easier to call vmcs_clear to a fixed per cpu buffer.
Performing list walking in interrupt context without locking in vmclear_local_loaded vmcss looks a bit scary. Not that locking would make it any better, as locking would simply add one more way to deadlock the system. Only an rcu list walk is at all safe. A list walk that modifies the list as vmclear_local_loaded_vmcss does is definitely not safe.
Eric
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 20 lines · Eric W. Biederman
Quoted 11 lines · Gleb Natapov
Quoted 10 lines · Eric W. Biederman
Quoted 4 lines · Zhang Yanfei
This patch adds an atomic notifier list named
crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.
crash_notifier_listick gag please no. Effectively this makes the kexec on panic code path undebuggable.Quoted 6 lines
Quoted 2 lines
Instead we need to use direct function calls to whatever you are doing.
The code walks linked list in kvm-intel module and calls vmclear on whatever it finds there. Since the function have to resides in kvm-intel module it cannot be called directly. Is callback pointer that is set by kvm-intel more acceptable?
Quoted 5 lines
Yes a specific callback function is more acceptable. Looking a little deeper
vmclear_local_loaded_vmcssis not particularly acceptable. It is doing a lot of work that is unnecessary to save the virtual registers on the kexec on panic path.
What work are you referring to in particular that may not be acceptable?
Quoted 3 lines
In fact I wonder if it might not just be easier to call
vmcs_clearto a fixed per cpu buffer.
There may be more than one vmcs loaded on a cpu, hence the list.
Quoted 6 lines
Performing list walking in interrupt context without locking in
vmclear_local_loadedvmcss looks a bit scary. Not that locking would make it any better, as locking would simply add one more way to deadlock the system. Only an rcu list walk is at all safe. A list walk that modifies the list asvmclear_local_loaded_vmcssdoes is definitely not safe.
The list vmclear_local_loaded walks is per cpu. Zhang's kvm patch disables kexec callback while list is modified.
--
Gleb.
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 21 lines · Gleb Natapov
Quoted 20 lines · Eric W. Biederman
Quoted 17 lines · Gleb Natapov
Quoted 7 lines · Eric W. Biederman
Quoted 4 lines · Zhang Yanfei
This patch adds an atomic notifier list named
crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.Quoted 5 lines
crash_notifier_listick gag please no. Effectively this makes the kexec on panic code path undebuggable.Instead we need to use direct function calls to whatever you are doing.
The code walks linked list in kvm-intel module and calls vmclear on whatever it finds there. Since the function have to resides in kvm-intel module it cannot be called directly. Is callback pointer that is set by kvm-intel more acceptable?
Quoted 7 lines
Quoted 5 lines
Yes a specific callback function is more acceptable. Looking a little deeper
vmclear_local_loaded_vmcssis not particularly acceptable. It is doing a lot of work that is unnecessary to save the virtual registers on the kexec on panic path.What work are you referring to in particular that may not be acceptable?
The unnecessary work that I was see is all of the software state changing. Unlinking things from linked lists flipping variables. None of that appears related to the fundamental issue saving cpu state.
Simply reusing a function that does more than what is strictly required makes me nervous. What is the chance that the function will grow with maintenance and add constructs that are not safe in a kexec on panic situtation.
Quoted 5 lines
Quoted 3 lines
In fact I wonder if it might not just be easier to call
vmcs_clearto a fixed per cpu buffer.There may be more than one vmcs loaded on a cpu, hence the list.
Quoted 8 lines
Quoted 6 lines
Performing list walking in interrupt context without locking in
vmclear_local_loadedvmcss looks a bit scary. Not that locking would make it any better, as locking would simply add one more way to deadlock the system. Only an rcu list walk is at all safe. A list walk that modifies the list asvmclear_local_loaded_vmcssdoes is definitely not safe.The list
vmclear_local_loadedwalks is per cpu. Zhang's kvm patch disables kexec callback while list is modified.
If the list is only modified on it's cpu and we are running on that cpu that does look like it will give the necessary protections. It isn't particularly clear at first glance that is the case unfortunately.
Eric
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 36 lines · Eric W. Biederman
Quoted 21 lines · Gleb Natapov
Quoted 20 lines · Eric W. Biederman
Quoted 17 lines · Gleb Natapov
Quoted 7 lines · Eric W. Biederman
Quoted 4 lines · Zhang Yanfei
This patch adds an atomic notifier list named
crash_notifier_list. Currently, when loading kvm-intel module, a notifier will be registered in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if needed.Quoted 5 lines
crash_notifier_listick gag please no. Effectively this makes the kexec on panic code path undebuggable.Instead we need to use direct function calls to whatever you are doing.
The code walks linked list in kvm-intel module and calls vmclear on whatever it finds there. Since the function have to resides in kvm-intel module it cannot be called directly. Is callback pointer that is set by kvm-intel more acceptable?
Quoted 7 lines
Quoted 5 lines
Yes a specific callback function is more acceptable. Looking a little deeper
vmclear_local_loaded_vmcssis not particularly acceptable. It is doing a lot of work that is unnecessary to save the virtual registers on the kexec on panic path.What work are you referring to in particular that may not be acceptable?
The unnecessary work that I was see is all of the software state changing. Unlinking things from linked lists flipping variables. None of that appears related to the fundamental issue saving cpu state.
Quoted 4 lines
Simply reusing a function that does more than what is strictly required makes me nervous. What is the chance that the function will grow with maintenance and add constructs that are not safe in a kexec on panic situtation.
So in summary,
1. a specific callback function instead of a notifier?
2. Instead of calling vmclear_local_loaded_vmcss, the vmclear operation will just call the vmclear on every vmcss loaded on the cpu?
like below:
static void crash_vmclear_local_loaded_vmcss(void)
{
int cpu = raw_smp_processor_id();
struct loaded_vmcs *v, *n; if (!crash_local_vmclear_enabled(cpu))
return;
list_for_each_entry_safe(v, n, &per_cpu(loaded_vmcss_on_cpu, cpu),
loaded_vmcss_on_cpu_link)
vmcs_clear(v->vmcs);}
right?
Thanks
Zhang
Quoted 21 lines
Quoted 6 lines
Quoted 4 lines
In fact I wonder if it might not just be easier to call
vmcs_clearto a fixed per cpu buffer.There may be more than one vmcs loaded on a cpu, hence the list.
Quoted 8 lines
Quoted 6 lines
Performing list walking in interrupt context without locking in
vmclear_local_loadedvmcss looks a bit scary. Not that locking would make it any better, as locking would simply add one more way to deadlock the system. Only an rcu list walk is at all safe. A list walk that modifies the list asvmclear_local_loaded_vmcssdoes is definitely not safe.The list
vmclear_local_loadedwalks is per cpu. Zhang's kvm patch disables kexec callback while list is modified.If the list is only modified on it's cpu and we are running on that cpu that does look like it will give the necessary protections. It isn't particularly clear at first glance that is the case unfortunately.
Eric
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 3 lines · Zhang Yanfei
So in summary,
1. a specific callback function instead of a notifier?
Yes.
Quoted 19 lines
2. Instead of calling
vmclear_local_loaded_vmcss, the vmclear operation will just call the vmclear on every vmcss loaded on the cpu?like below: static void crash_vmclear_local_loaded_vmcss(void) { int cpu = raw_smp_processor_id(); struct loaded_vmcs *v, *n; if (!crash_local_vmclear_enabled(cpu)) return; list_for_each_entry_safe(v, n, &per_cpu(loaded_vmcss_on_cpu, cpu), loaded_vmcss_on_cpu_link) vmcs_clear(v->vmcs); } right?
Yeah that looks good. I would do list_for_each_entry because the list isn't changing.
Eric
Re: [PATCH v8 1/2] x86/kexec: add a new atomic notifier list for kdump
Quoted 26 lines · Eric W. Biederman
Quoted 3 lines · Zhang Yanfei
So in summary,
1. a specific callback function instead of a notifier?
Yes.
Quoted 18 lines
2. Instead of calling
vmclear_local_loaded_vmcss, the vmclear operation will just call the vmclear on every vmcss loaded on the cpu?like below: static void crash_vmclear_local_loaded_vmcss(void) { int cpu = raw_smp_processor_id(); struct loaded_vmcs *v, *n; if (!crash_local_vmclear_enabled(cpu)) return; list_for_each_entry_safe(v, n, &per_cpu(loaded_vmcss_on_cpu, cpu), loaded_vmcss_on_cpu_link) vmcs_clear(v->vmcs); }
Quoted 4 lines
Quoted 1 line
right?
Yeah that looks good. I would do
list_for_each_entrybecause the list isn't changing.
OK.
I will update the patch and resend it.
Zhang
PATCH v8 2/2 KVM-INTEL: add a notifier and a bitmap to support VMCLEAR in kdump
In reply to Zhang YanfeiThe notifier will be registered in crash_notifier_list when loading kvm-intel module. And the bitmap indicates whether we should do VMCLEAR operation in kdump. The bits in the bitmap are set/unset according to different conditions.
--- arch/x86/kvm/vmx.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 70 insertions(+), 0 deletions(-)
arch/x86/kvm/vmx.c +70 -0
@@ -41,6 +41,7 @@#include <asm/i387.h> #include <asm/xcr.h> #include <asm/perf_event.h> +#include <asm/kexec.h> #include "trace.h"
@@ -963,6 +964,49 @@ static void vmcs_load(struct vmcs *vmcs) vmcs, phys_addr); } +#ifdef CONFIG_KEXEC +/* +* This bitmap is used to indicate whether the vmclear +* operation is enabled on all cpus. All disabled by +* default. +*/ +static cpumask_t crash_vmclear_enabled_bitmap =CPU_MASK_NONE ; + +static inline void crash_enable_local_vmclear (int cpu) +{ +cpumask_set_cpu (cpu, &crash_vmclear_enabled_bitmap); +} + +static inline void crash_disable_local_vmclear (int cpu) +{ +cpumask_clear_cpu (cpu, &crash_vmclear_enabled_bitmap); +} + +static inline int crash_local_vmclear_enabled (int cpu) +{ +return cpumask_test_cpu (cpu, &crash_vmclear_enabled_bitmap); +} + +static void vmclear_local_loaded_vmcss (void ); +static int crash_vmclear_local_loaded_vmcss (struct notifier_block *this, +unsigned long val,void *ptr) +{ +int cpu =raw_smp_processor_id (); + +if (crash_local_vmclear_enabled (cpu)) +vmclear_local_loaded_vmcss (); + +return NOTIFY_DONE ; +} + +static struct notifier_block crash_vmclear_notifier = { + .notifier_call = crash_vmclear_local_loaded_vmcss, +}; +#else +static inline void crash_enable_local_vmclear (int cpu) { } +static inline void crash_disable_local_vmclear (int cpu) { } +#endif /* CONFIG_KEXEC */ +static void __loaded_vmcs_clear (void *arg) {struct loaded_vmcs *loaded_vmcs = arg;
@@ -972,8 +1016,10 @@ static void __loaded_vmcs_clear(void *arg)return ;/* vcpu migration can race with cpu offline */ if (per_cpu (current_vmcs, cpu) == loaded_vmcs->vmcs)per_cpu (current_vmcs, cpu) =NULL ; +crash_disable_local_vmclear (cpu);list_del (&loaded_vmcs->loaded_vmcss_on_cpu_link);loaded_vmcs_init (loaded_vmcs); +crash_enable_local_vmclear (cpu); }static void loaded_vmcs_clear (struct loaded_vmcs *loaded_vmcs)
@@ -1491,8 +1537,10 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)kvm_make_request (KVM_REQ_TLB_FLUSH , vcpu);local_irq_disable (); +crash_disable_local_vmclear (cpu);list_add (&vmx->loaded_vmcs->loaded_vmcss_on_cpu_link, &per_cpu (loaded_vmcss_on_cpu, cpu)); +crash_enable_local_vmclear (cpu);local_irq_enable ();/*
@@ -2302,6 +2350,18 @@ static int hardware_enable(void *garbage)return -EBUSY ;INIT_LIST_HEAD (&per_cpu (loaded_vmcss_on_cpu, cpu)); + +/* +* Now we can enable the vmclear operation in kdump +* since the loaded_vmcss_on_cpu list on this cpu +* has been initialized. +* +* Though the cpu is not in VMX operation now, there +* is no problem to enable the vmclear operation +* for the loaded_vmcss_on_cpu list is empty! +*/ +crash_enable_local_vmclear (cpu); +rdmsrl (MSR_IA32_FEATURE_CONTROL , old); test_bits =FEATURE_CONTROL_LOCKED ;
@@ -7230,6 +7290,11 @@ static int __init vmx_init(void)if (r) goto out3; +#ifdef CONFIG_KEXEC +atomic_notifier_chain_register (&crash_notifier_list, + &crash_vmclear_notifier); +#endif +vmx_disable_intercept_for_msr (MSR_FS_BASE , false);vmx_disable_intercept_for_msr (MSR_GS_BASE , false);vmx_disable_intercept_for_msr (MSR_KERNEL_GS_BASE , true);
@@ -7265,6 +7330,11 @@ static void __exit vmx_exit(void)free_page ((unsigned long )vmx_io_bitmap_b);free_page ((unsigned long )vmx_io_bitmap_a); +#ifdef CONFIG_KEXEC +atomic_notifier_chain_unregister (&crash_notifier_list, + &crash_vmclear_notifier); +#endif +kvm_exit (); }
Signature · 1 line
1.7.1
Quoted 10 lines · Zhang Yanfei
Currently, kdump just makes all the logical processors leave VMX operation by executing VMXOFF instruction, so any VMCSs active on the logical processors may be corrupted. But, sometimes, we need the VMCSs to debug guest images contained in the host vmcore. To prevent the corruption, we should VMCLEAR the VMCSs before executing the VMXOFF instruction.
The patch set provides a way to VMCLEAR vmcss related to guests on all cpus before executing the VMXOFF when doing kdump. This is used to ensure the VMCSs in the vmcore updated and non-corrupted.
Looks fine to me, but kexec part should get acks from exec maintainers.
Quoted 30 lines
Changelog from v7 to v8:
1. KEXEC: regression for using namecrash_notifier_listand remove comments related to KVM
and just call functionatomic_notifier_call_chaindirectly.Changelog from v6 to v7:
1. KVM-INTEL: inhardware_disable, we needn't disable the vmclear, so remove it.Changelog from v5 to v6:
1. KEXEC: the atomic notifier list renamed:crash_notifier_list --> vmclear_notifier_list2. KVM-INTEL: provide empty functions if
CONFIG_KEXECis not defined and remove unnecessary #ifdef's.Changelog from v4 to v5:
1. use an atomic notifier instead of function call, so have all the vmclear codes invmx.c.Changelog from v3 to v4:
1. add a new percpu variablevmclear_skippedto skip vmclear in kdump in some conditions.Changelog from v2 to v3:
1. remove unnecessary conditions in functioncpu_emergency_clear_loaded_vmcssas Marcelo suggested.Changelog from v1 to v2:
1. remove the sysctl and clear VMCSs unconditionally.
Quoted 8 lines
Zhang Yanfei (2):
x86/kexec: add a new atomic notifier list for kdump
KVM-INTEL: add a notifier and a bitmap to support VMCLEAR in kdumparch/x86/include/asm/kexec.h | 2 + arch/x86/kernel/crash.c | 9 +++++ arch/x86/kvm/vmx.c | 70 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 81 insertions(+), 0 deletions(-)
--
Gleb.
Quoted 7 lines · Gleb Natapov
Quoted 6 lines · Zhang Yanfei
Currently, kdump just makes all the logical processors leave VMX operation by executing VMXOFF instruction, so any VMCSs active on the logical processors may be corrupted. But, sometimes, we need the VMCSs to debug guest images contained in the host vmcore. To prevent the corruption, we should VMCLEAR the VMCSs before executing the VMXOFF instruction.
Quoted 5 lines
Quoted 4 lines
The patch set provides a way to VMCLEAR vmcss related to guests on all cpus before executing the VMXOFF when doing kdump. This is used to ensure the VMCSs in the vmcore updated and non-corrupted.
Looks fine to me, but kexec part should get acks from exec maintainers.
Thanks. I will ask the exec maintainer.
Quoted 35 lines
Quoted 35 lines
Changelog from v7 to v8:
1. KEXEC: regression for using namecrash_notifier_listand remove comments related to KVM
and just call functionatomic_notifier_call_chaindirectly.Changelog from v6 to v7:
1. KVM-INTEL: inhardware_disable, we needn't disable the vmclear, so remove it.Changelog from v5 to v6:
1. KEXEC: the atomic notifier list renamed:crash_notifier_list --> vmclear_notifier_list2. KVM-INTEL: provide empty functions if
CONFIG_KEXECis not defined and remove unnecessary #ifdef's.Changelog from v4 to v5:
1. use an atomic notifier instead of function call, so have all the vmclear codes invmx.c.Changelog from v3 to v4:
1. add a new percpu variablevmclear_skippedto skip vmclear in kdump in some conditions.Changelog from v2 to v3:
1. remove unnecessary conditions in functioncpu_emergency_clear_loaded_vmcssas Marcelo suggested.Changelog from v1 to v2:
1. remove the sysctl and clear VMCSs unconditionally.Zhang Yanfei (2):
x86/kexec: add a new atomic notifier list for kdump
KVM-INTEL: add a notifier and a bitmap to support VMCLEAR in kdump
Quoted 8 lines
Quoted 4 lines
arch/x86/include/asm/kexec.h | 2 + arch/x86/kernel/crash.c | 9 +++++ arch/x86/kvm/vmx.c | 70 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 81 insertions(+), 0 deletions(-)--
Gleb.
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hello Eric
Would you help review the patch, and give some comments, please ?
Thanks
Zhang
Quoted 48 lines · Zhang Yanfei
Currently, kdump just makes all the logical processors leave VMX operation by executing VMXOFF instruction, so any VMCSs active on the logical processors may be corrupted. But, sometimes, we need the VMCSs to debug guest images contained in the host vmcore. To prevent the corruption, we should VMCLEAR the VMCSs before executing the VMXOFF instruction.
The patch set provides a way to VMCLEAR vmcss related to guests on all cpus before executing the VMXOFF when doing kdump. This is used to ensure the VMCSs in the vmcore updated and non-corrupted.
Changelog from v7 to v8:
1. KEXEC: regression for using namecrash_notifier_listand remove comments related to KVM
and just call functionatomic_notifier_call_chaindirectly.Changelog from v6 to v7:
1. KVM-INTEL: inhardware_disable, we needn't disable the vmclear, so remove it.Changelog from v5 to v6:
1. KEXEC: the atomic notifier list renamed:crash_notifier_list --> vmclear_notifier_list2. KVM-INTEL: provide empty functions if
CONFIG_KEXECis not defined and remove unnecessary #ifdef's.Changelog from v4 to v5:
1. use an atomic notifier instead of function call, so have all the vmclear codes invmx.c.Changelog from v3 to v4:
1. add a new percpu variablevmclear_skippedto skip vmclear in kdump in some conditions.Changelog from v2 to v3:
1. remove unnecessary conditions in functioncpu_emergency_clear_loaded_vmcssas Marcelo suggested.Changelog from v1 to v2:
1. remove the sysctl and clear VMCSs unconditionally.Zhang Yanfei (2):
x86/kexec: add a new atomic notifier list for kdump
KVM-INTEL: add a notifier and a bitmap to support VMCLEAR in kdumparch/x86/include/asm/kexec.h | 2 + arch/x86/kernel/crash.c | 9 +++++ arch/x86/kvm/vmx.c | 70 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 81 insertions(+), 0 deletions(-)