At 04/17/2012 06:59 PM, Avi Kivity Wrote:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>> 1cba8c0: 0000127b00000009 53434d5600000000 ....{.......VMCS
>>>> 1cba8d0: 000000004f464e49 4e4f495349564552 INFO....REVISION
>>>> 1cba8e0: 49460a643d44495f 5f4e495028444c45 _ID=d.FIELD(PIN_
>>>> 1cba8f0: 4d565f4445534142 4f435f434558455f BASED_VM_EXEC_CO
>>>> 1cba900: 303d294c4f52544e 0a30383130343831 NTROL)=01840180.
>>>> 1cba910: 504328444c454946 5f44455341425f55 FIELD(CPU_BASED_
>>>> 1cba920: 5f434558455f4d56 294c4f52544e4f43 VM_EXEC_CONTROL)
>>>> 1cba930: 393130343931303d 28444c4549460a30 =01940190.FIELD(
>>>> 1cba940: 5241444e4f434553 4558455f4d565f59 SECONDARY_VM_EXE
>>>> 1cba950: 4f52544e4f435f43 30346566303d294c C_CONTROL)=0fe40
>>>> 1cba960: 4c4549460a306566 4958455f4d562844 fe0.FIELD(VM_EXI
>>>> 1cba970: 4f52544e4f435f54 346531303d29534c T_CONTROLS)=01e4
>>>> 1cba980: 4549460a30653130 4e455f4d5628444c 01e0.FIELD(VM_EN
>>>> 1cba990: 544e4f435f595254 33303d29534c4f52 TRY_CONTROLS)=03
>>>> 1cba9a0: 460a303133303431 45554728444c4549 140310.FIELD(GUE
>>>> 1cba9b0: 45535f53455f5453 3d29524f5443454c ST_ES_SELECTOR)=
>>>> 1cba9c0: 4549460a30303530 545345554728444c 0500.FIELD(GUEST
>>>> 1cba9d0: 454c45535f53435f 35303d29524f5443 _CS_SELECTOR)=05
>>>> ......
>>>>
>>>> TODO:
>>>> 1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>> into vmcore.
>>>> 2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>> core file. To do this, we will modify kernel core dumper, gdb gcore
>>>> and crash gcore.
>>>> 3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>> host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>> its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump.
>
> Okay. Do you expect it to help in debugging the crash? Did you have
> cases where it would help?
>
>>
>> For scenario 2, we also want the guest's registers values to be dumped into
>> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
>
> Why? If qemu crashed it is because of an internal qemu fault. If any
> guest registers were involved, they would have been decoded by qemu
> previously and would be present in the stack trace (for example mmio
> address/data).
Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
The guest registers are stored in the kernel, and qemu does not call
cpu_synchronize_state() to get guest register. So I donot understand
why the registers woubld be present int the stack trace...
Thanks
Wen Congyang
>
>> Is this what you want?
>>
>
> Yes. I'm trying to understand if the feature would be useful in real life.
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
