Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary

2012-10-18 Thread Avi Kivity
On 10/18/2012 03:12 AM, Zhang Yanfei wrote:
 于 2012年10月17日 18:16, Avi Kivity 写道:
 On 10/17/2012 04:28 AM, Zhang Yanfei wrote:
 于 2012年10月15日 23:43, Avi Kivity 写道:
 On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
 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.

 How have you verified that VMXOFF doesn't flush cached VMCSs already?


 I tried some tests, for example, I made copies for every vmcs, and in the 
 kdump
 path, I backed up all the loaded vmcs into the copies before vmxoff.
 After generating the vmcore, I retrieve the vmcss and their copies, and 
 compare them,
 no differences.

 Another test is using VMCLEAR to clear all the loaded vmcs before VMXOFF,
 and compare the vmcss and their copies, there are indeed differences 
 between the
 vmcs and its copy.

 I know the tests may be not so convincing, for example, I used memcpy to 
 back up
 the vmcss and it is an ordinary memory operation. But to ensure the 
 non-corruption
 of the vmcss in the vmcore, I think we should VMCLEAR the vmcss before 
 VMXOFF just
 as the Intel spec says.
 
 Sorry, I was unclear -- I was referring to the spec, I wasn't sure
 whether VMXOFF is defined to flush VMCSes or whether it just invalidates
 on-chip caches so that it won't flush them out in the future, corrupting
 memory.  We don't want to depend on actual behaviour as it may change
 with future version.
 
 Copying some Intel folk, maybe they can clarify it.
 
 
 Yes, the Intel spec says may be about the VMCS-corruption thing. From
 chapter 24.10.1 in Intel® 64 and IA-32 Architectures Software Developer’s
 Manual Volume 3C:System Programming Guide, Part 3, there is the description:
 
 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 VMCLEAR 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).
 
 Our purpose is to make sure the VMCSs in the vmcore are updated and 
 non-corrupted. So
 according to the description above, no matter whether VMXOFF is defined to 
 flush
 VMCSs or whether it just invalidates on-chip caches, we'd better VMCLEAR the
 VMCSs before executing the VMXOFF.

Ok, that's clear then.  So all we need is to remove the sysctl and clear
VMCSs unconditionally.



-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary

2012-10-18 Thread Zhang Yanfei
于 2012年10月18日 18:55, Avi Kivity 写道:
 On 10/18/2012 03:12 AM, Zhang Yanfei wrote:
 于 2012年10月17日 18:16, Avi Kivity 写道:
 On 10/17/2012 04:28 AM, Zhang Yanfei wrote:
 于 2012年10月15日 23:43, Avi Kivity 写道:
 On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
 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.

 How have you verified that VMXOFF doesn't flush cached VMCSs already?


 I tried some tests, for example, I made copies for every vmcs, and in the 
 kdump
 path, I backed up all the loaded vmcs into the copies before vmxoff.
 After generating the vmcore, I retrieve the vmcss and their copies, and 
 compare them,
 no differences.

 Another test is using VMCLEAR to clear all the loaded vmcs before VMXOFF,
 and compare the vmcss and their copies, there are indeed differences 
 between the
 vmcs and its copy.

 I know the tests may be not so convincing, for example, I used memcpy to 
 back up
 the vmcss and it is an ordinary memory operation. But to ensure the 
 non-corruption
 of the vmcss in the vmcore, I think we should VMCLEAR the vmcss before 
 VMXOFF just
 as the Intel spec says.

 Sorry, I was unclear -- I was referring to the spec, I wasn't sure
 whether VMXOFF is defined to flush VMCSes or whether it just invalidates
 on-chip caches so that it won't flush them out in the future, corrupting
 memory.  We don't want to depend on actual behaviour as it may change
 with future version.

 Copying some Intel folk, maybe they can clarify it.


 Yes, the Intel spec says may be about the VMCS-corruption thing. From
 chapter 24.10.1 in Intel® 64 and IA-32 Architectures Software Developer’s
 Manual Volume 3C:System Programming Guide, Part 3, there is the description:

 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 VMCLEAR 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).

 Our purpose is to make sure the VMCSs in the vmcore are updated and 
 non-corrupted. So
 according to the description above, no matter whether VMXOFF is defined to 
 flush
 VMCSs or whether it just invalidates on-chip caches, we'd better VMCLEAR the
 VMCSs before executing the VMXOFF.
 
 Ok, that's clear then.  So all we need is to remove the sysctl and clear
 VMCSs unconditionally.
 

OK, I'll make the new patch and resend it again.

Thanks
Zhang Yanfei

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary

2012-10-17 Thread Avi Kivity
On 10/17/2012 04:28 AM, Zhang Yanfei wrote:
 于 2012年10月15日 23:43, Avi Kivity 写道:
 On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
 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.
 
 How have you verified that VMXOFF doesn't flush cached VMCSs already?
 
 
 I tried some tests, for example, I made copies for every vmcs, and in the 
 kdump
 path, I backed up all the loaded vmcs into the copies before vmxoff.
 After generating the vmcore, I retrieve the vmcss and their copies, and 
 compare them,
 no differences.
 
 Another test is using VMCLEAR to clear all the loaded vmcs before VMXOFF,
 and compare the vmcss and their copies, there are indeed differences between 
 the
 vmcs and its copy.
 
 I know the tests may be not so convincing, for example, I used memcpy to back 
 up
 the vmcss and it is an ordinary memory operation. But to ensure the 
 non-corruption
 of the vmcss in the vmcore, I think we should VMCLEAR the vmcss before VMXOFF 
 just
 as the Intel spec says.

Sorry, I was unclear -- I was referring to the spec, I wasn't sure
whether VMXOFF is defined to flush VMCSes or whether it just invalidates
on-chip caches so that it won't flush them out in the future, corrupting
memory.  We don't want to depend on actual behaviour as it may change
with future version.

Copying some Intel folk, maybe they can clarify it.

 

 The patch set provides an alternative way to clear VMCSs related to guests
 on all cpus when host is doing kdump.

 
 I'm not sure the sysctl is really necessary.  The only reason to turn if
 off is if the corruption is so severe that the loaded vmcs list itself
 causes a crash.  I think it should be rare enough that we can do it
 unconditionally.
 
 
 You mean not using sysctl and just let VMCLEAR-VMCSS be a default behaviour? 
 If so,
 I agree with you.

Yes, that's what I meant.


-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary

2012-10-17 Thread Zhang Yanfei
于 2012年10月17日 18:16, Avi Kivity 写道:
 On 10/17/2012 04:28 AM, Zhang Yanfei wrote:
 于 2012年10月15日 23:43, Avi Kivity 写道:
 On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
 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.

 How have you verified that VMXOFF doesn't flush cached VMCSs already?


 I tried some tests, for example, I made copies for every vmcs, and in the 
 kdump
 path, I backed up all the loaded vmcs into the copies before vmxoff.
 After generating the vmcore, I retrieve the vmcss and their copies, and 
 compare them,
 no differences.

 Another test is using VMCLEAR to clear all the loaded vmcs before VMXOFF,
 and compare the vmcss and their copies, there are indeed differences between 
 the
 vmcs and its copy.

 I know the tests may be not so convincing, for example, I used memcpy to 
 back up
 the vmcss and it is an ordinary memory operation. But to ensure the 
 non-corruption
 of the vmcss in the vmcore, I think we should VMCLEAR the vmcss before 
 VMXOFF just
 as the Intel spec says.
 
 Sorry, I was unclear -- I was referring to the spec, I wasn't sure
 whether VMXOFF is defined to flush VMCSes or whether it just invalidates
 on-chip caches so that it won't flush them out in the future, corrupting
 memory.  We don't want to depend on actual behaviour as it may change
 with future version.
 
 Copying some Intel folk, maybe they can clarify it.
 

Yes, the Intel spec says may be about the VMCS-corruption thing. From
chapter 24.10.1 in Intel® 64 and IA-32 Architectures Software Developer’s
Manual Volume 3C:System Programming Guide, Part 3, there is the description:

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 VMCLEAR 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).

Our purpose is to make sure the VMCSs in the vmcore are updated and 
non-corrupted. So
according to the description above, no matter whether VMXOFF is defined to flush
VMCSs or whether it just invalidates on-chip caches, we'd better VMCLEAR the
VMCSs before executing the VMXOFF.

Thanks
Zhang Yanfei
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary

2012-10-15 Thread Avi Kivity
On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
 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.

How have you verified that VMXOFF doesn't flush cached VMCSs already?

 
 The patch set provides an alternative way to clear VMCSs related to guests
 on all cpus when host is doing kdump.
 

I'm not sure the sysctl is really necessary.  The only reason to turn if
off is if the corruption is so severe that the loaded vmcs list itself
causes a crash.  I think it should be rare enough that we can do it
unconditionally.

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary

2012-10-12 Thread 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 an alternative way to clear VMCSs related to guests
on all cpus when host is doing kdump.

zhangyanfei (3):
  x86/kexec: clear vmcss on all cpus if necessary
  KVM: make crash_clear_loaded_vmcss valid when kvm_intel is loaded
  sysctl: introduce a new interface to control kdump-vmcs-clear
behaviour

 Documentation/sysctl/kernel.txt |8 
 arch/x86/include/asm/kexec.h|3 +++
 arch/x86/kernel/crash.c |   23 +++
 arch/x86/kvm/vmx.c  |9 +
 kernel/sysctl.c |   10 ++
 5 files changed, 53 insertions(+), 0 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html