From: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
To: Avi Kivity <avi@redhat.com>
Cc: x86@kernel.org, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
linux-doc@vger.kernel.org, "Hao, Xudong" <xudong.hao@intel.com>,
mtosatti@redhat.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, "Nakajima,
Jun" <jun.nakajima@intel.com>
Subject: Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary
Date: Fri, 19 Oct 2012 12:51:00 +0800 [thread overview]
Message-ID: <5080DC34.1080503@cn.fujitsu.com> (raw)
In-Reply-To: <507FE020.7040805@redhat.com>
于 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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
To: Avi Kivity <avi@redhat.com>
Cc: x86@kernel.org, kexec@lists.infradead.org,
linux-doc@vger.kernel.org, mtosatti@redhat.com,
linux-kernel@vger.kernel.org,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Hao, Xudong" <xudong.hao@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary
Date: Fri, 19 Oct 2012 12:51:00 +0800 [thread overview]
Message-ID: <5080DC34.1080503@cn.fujitsu.com> (raw)
In-Reply-To: <507FE020.7040805@redhat.com>
于 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
next prev parent reply other threads:[~2012-10-19 4:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 6:40 [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary Zhang Yanfei
2012-10-12 6:40 ` Zhang Yanfei
2012-10-12 6:43 ` [PATCH 1/3] x86/kexec: clear vmcss on all cpus " Zhang Yanfei
2012-10-12 6:43 ` Zhang Yanfei
2012-10-12 6:44 ` [PATCH 2/3] KVM: make crash_clear_loaded_vmcss valid when kvm_intel is loaded Zhang Yanfei
2012-10-12 6:44 ` Zhang Yanfei
2012-10-12 6:45 ` [PATCH 3/3] sysctl: introduce a new interface to control kdump-vmcs-clear behaviour Zhang Yanfei
2012-10-12 6:45 ` Zhang Yanfei
2012-10-15 15:43 ` [PATCH 0/3] x86: clear vmcss on all cpus when doing kdump if necessary Avi Kivity
2012-10-15 15:43 ` Avi Kivity
2012-10-15 15:43 ` Avi Kivity
2012-10-17 2:28 ` Zhang Yanfei
2012-10-17 2:28 ` Zhang Yanfei
2012-10-17 10:16 ` Avi Kivity
2012-10-17 10:16 ` Avi Kivity
2012-10-18 1:12 ` Zhang Yanfei
2012-10-18 1:12 ` Zhang Yanfei
2012-10-18 10:55 ` Avi Kivity
2012-10-18 10:55 ` Avi Kivity
2012-10-19 4:51 ` Zhang Yanfei [this message]
2012-10-19 4:51 ` Zhang Yanfei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5080DC34.1080503@cn.fujitsu.com \
--to=zhangyanfei@cn.fujitsu.com \
--cc=avi@redhat.com \
--cc=jun.nakajima@intel.com \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=x86@kernel.org \
--cc=xudong.hao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.