Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
On 04/22/2012 01:33 PM, Gleb Natapov wrote: > > > > What I don't understand is why you are interested in the guest machine > > at all, if it was qemu that crashed. > > > It would be interesting to extract enough information from the core to be > able to restart the guest from the point where qemu crashed, but > decoding VMCS is not enough for that. Interesting idea. It should be possible if you attach all kvm state to the core (and do quite a lot of digging to recover device model state). -- 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/4] Export offsets of VMCS fields as note information for kdump
On Sun, Apr 22, 2012 at 12:58:35PM +0300, Avi Kivity wrote: > On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote: > > From: Avi Kivity > > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information > > for kdump > > Date: Thu, 19 Apr 2012 15:08:00 +0300 > > > > > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote: > > >> >> It would be not helpful for the qemu crash case you are concerned > > >> >> about. We want to use the guest state data to look into guest > > >> >> machine's image in the crasshed qemu. > > >> > > > >> > Why? > > >> > > > >> > > >> It seems natural to check the situation from guest machine's side when > > >> qemu crashs. Suppose a service is running on the guest machine, and > > >> then the qemu crash. Then, we may need to know the details of the > > >> progress of the service if it's important. What has been successfully > > >> done, and what has not yet. > > > > > > How can a service on the guest be related to a qemu crash? And how > > > would guest registers help? > > > > I don't mean the service is related to qemu's crash. When qemu > > crashes, then the guest machine also crashes (although it doesn't > > notice anything). What I'm interested in here is guest machine side, > > not qemu side. I want to debug guest machine, not qemu. > > There is no bug in the guest, so why debug it? > > It's similar to pulling out the power from a server and wanting to > inspect the registers and memory at the time the cpu died. Even if it's > possible, you don't gain any information from it. > > > > > > > You can extract the list of running processes from a qemu crash dump > > > without looking at guest registers. And most vcpus are running > > > asynchronously to qemu, so their register contents is irrelevant (if a > > > vcpu is running synchronously with qemu - it just exited to qemu and is > > > waiting for a response - then you'd see the details in qemu's call stack). > > > > > > > Just as you say, we can refer to guest machine's memory without guest > > registers. > > > > The definitely necessary data in vmcs are RSP and RIP, which are not > > saved in anywhare of kvm module. The two registers are needed for back > > tracing to determine what processsing is being done on the guest > > machine at qemu crash. > > What I don't understand is why you are interested in the guest machine > at all, if it was qemu that crashed. > It would be interesting to extract enough information from the core to be able to restart the guest from the point where qemu crashed, but decoding VMCS is not enough for that. -- Gleb. -- 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/4] Export offsets of VMCS fields as note information for kdump
On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote: > From: Avi Kivity > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information > for kdump > Date: Thu, 19 Apr 2012 15:08:00 +0300 > > > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote: > >> >> It would be not helpful for the qemu crash case you are concerned > >> >> about. We want to use the guest state data to look into guest > >> >> machine's image in the crasshed qemu. > >> > > >> > Why? > >> > > >> > >> It seems natural to check the situation from guest machine's side when > >> qemu crashs. Suppose a service is running on the guest machine, and > >> then the qemu crash. Then, we may need to know the details of the > >> progress of the service if it's important. What has been successfully > >> done, and what has not yet. > > > > How can a service on the guest be related to a qemu crash? And how > > would guest registers help? > > I don't mean the service is related to qemu's crash. When qemu > crashes, then the guest machine also crashes (although it doesn't > notice anything). What I'm interested in here is guest machine side, > not qemu side. I want to debug guest machine, not qemu. There is no bug in the guest, so why debug it? It's similar to pulling out the power from a server and wanting to inspect the registers and memory at the time the cpu died. Even if it's possible, you don't gain any information from it. > > > > You can extract the list of running processes from a qemu crash dump > > without looking at guest registers. And most vcpus are running > > asynchronously to qemu, so their register contents is irrelevant (if a > > vcpu is running synchronously with qemu - it just exited to qemu and is > > waiting for a response - then you'd see the details in qemu's call stack). > > > > Just as you say, we can refer to guest machine's memory without guest > registers. > > The definitely necessary data in vmcs are RSP and RIP, which are not > saved in anywhare of kvm module. The two registers are needed for back > tracing to determine what processsing is being done on the guest > machine at qemu crash. What I don't understand is why you are interested in the guest machine at all, if it was qemu that crashed. > There are other useful data in vmcs, but even if we don't have them, > we can do what we want to do in exchange of usability. > > For example, we want IA32_EFER.LMA to determine whether guest machine > is in 32-bit or 64-bit mode. But there are only two modes, we can > perhaps try these in order in an ad-hoc way. > > Other control registers are also useful, but they are not so important > than definitely needed. > If this is your interest, then the data should be encoded in a vendor agnostic way. That is, not as lists of vmcs fields, but instead guest registers. This can be implemented for both vmx and svm. However this is secondary to the question of why we need to do this at all. -- 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/4] Export offsets of VMCS fields as note information for kdump
From: Avi Kivity Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump Date: Thu, 19 Apr 2012 15:08:00 +0300 > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote: >> >> It would be not helpful for the qemu crash case you are concerned >> >> about. We want to use the guest state data to look into guest >> >> machine's image in the crasshed qemu. >> > >> > Why? >> > >> >> It seems natural to check the situation from guest machine's side when >> qemu crashs. Suppose a service is running on the guest machine, and >> then the qemu crash. Then, we may need to know the details of the >> progress of the service if it's important. What has been successfully >> done, and what has not yet. > > How can a service on the guest be related to a qemu crash? And how > would guest registers help? I don't mean the service is related to qemu's crash. When qemu crashes, then the guest machine also crashes (although it doesn't notice anything). What I'm interested in here is guest machine side, not qemu side. I want to debug guest machine, not qemu. > > You can extract the list of running processes from a qemu crash dump > without looking at guest registers. And most vcpus are running > asynchronously to qemu, so their register contents is irrelevant (if a > vcpu is running synchronously with qemu - it just exited to qemu and is > waiting for a response - then you'd see the details in qemu's call stack). > Just as you say, we can refer to guest machine's memory without guest registers. The definitely necessary data in vmcs are RSP and RIP, which are not saved in anywhare of kvm module. The two registers are needed for back tracing to determine what processsing is being done on the guest machine at qemu crash. There are other useful data in vmcs, but even if we don't have them, we can do what we want to do in exchange of usability. For example, we want IA32_EFER.LMA to determine whether guest machine is in 32-bit or 64-bit mode. But there are only two modes, we can perhaps try these in order in an ad-hoc way. Other control registers are also useful, but they are not so important than definitely needed. Thanks. HATAYAMA, Daisuke -- 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/4] Export offsets of VMCS fields as note information for kdump
On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote: > >> It would be not helpful for the qemu crash case you are concerned > >> about. We want to use the guest state data to look into guest > >> machine's image in the crasshed qemu. > > > > Why? > > > > It seems natural to check the situation from guest machine's side when > qemu crashs. Suppose a service is running on the guest machine, and > then the qemu crash. Then, we may need to know the details of the > progress of the service if it's important. What has been successfully > done, and what has not yet. How can a service on the guest be related to a qemu crash? And how would guest registers help? You can extract the list of running processes from a qemu crash dump without looking at guest registers. And most vcpus are running asynchronously to qemu, so their register contents is irrelevant (if a vcpu is running synchronously with qemu - it just exited to qemu and is waiting for a response - then you'd see the details in qemu's call stack). -- 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/4] Export offsets of VMCS fields as note information for kdump
From: Avi Kivity Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump Date: Thu, 19 Apr 2012 14:31:56 +0300 > On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote: >> >> The reason why we want to retrieve guest machine's memory image as >> >> crash dump is that then we can debug guest machine's status using >> >> symbolic debugger such as gdb and crash utility. >> >> >> >> This is very useful. Please consider the situation where engineers are >> >> forced to look into guest machine's memory image through qemu-kvm's >> >> process core dump using gdb without any symbolic information. It's >> >> very inefficient. >> > >> > I still don't follow. If qemu crashed, the values in guest registers >> > are irrelevant. In what way can the help debug the qemu crash? >> > >> >> It would be not helpful for the qemu crash case you are concerned >> about. We want to use the guest state data to look into guest >> machine's image in the crasshed qemu. > > Why? > It seems natural to check the situation from guest machine's side when qemu crashs. Suppose a service is running on the guest machine, and then the qemu crash. Then, we may need to know the details of the progress of the service if it's important. What has been successfully done, and what has not yet. Thanks. HATAYAMA, Daisuke -- 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/4] Export offsets of VMCS fields as note information for kdump
On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote: > >> The reason why we want to retrieve guest machine's memory image as > >> crash dump is that then we can debug guest machine's status using > >> symbolic debugger such as gdb and crash utility. > >> > >> This is very useful. Please consider the situation where engineers are > >> forced to look into guest machine's memory image through qemu-kvm's > >> process core dump using gdb without any symbolic information. It's > >> very inefficient. > > > > I still don't follow. If qemu crashed, the values in guest registers > > are irrelevant. In what way can the help debug the qemu crash? > > > > It would be not helpful for the qemu crash case you are concerned > about. We want to use the guest state data to look into guest > machine's image in the crasshed qemu. Why? -- 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/4] Export offsets of VMCS fields as note information for kdump
From: Avi Kivity Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump Date: Thu, 19 Apr 2012 13:42:42 +0300 > On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote: >> From: Avi Kivity >> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information >> for kdump >> Date: Wed, 18 Apr 2012 14:56:39 +0300 >> >> > On 04/18/2012 12:49 PM, zhangyanfei wrote: >> >> >> >> >> > >> >> > What type of resource? Can you give an example? >> >> > >> >> Sorry. No concrete example for now. >> >> >> >> We are developing this on a conservative policy and I have put the vmcs >> >> processing >> >> in a new module in patch set v2 as you required. The new module is >> >> auto-loaded when >> >> the vmx cpufeature is detected and it depends on module kvm-intel. >> >> Loading and unloading >> >> this module will have no side effect on the running guests. >> >> >> >> And one thing I have to stress is that, we can see guest image as crash >> >> dump from >> >> guest machine's view if we have the vmcsinfo, this itself is useful. >> > >> > Why is it useful? Without a concrete example, it's hard to justify the >> > code bloat. >> > >> >> The reason why we want to retrieve guest machine's memory image as >> crash dump is that then we can debug guest machine's status using >> symbolic debugger such as gdb and crash utility. >> >> This is very useful. Please consider the situation where engineers are >> forced to look into guest machine's memory image through qemu-kvm's >> process core dump using gdb without any symbolic information. It's >> very inefficient. > > I still don't follow. If qemu crashed, the values in guest registers > are irrelevant. In what way can the help debug the qemu crash? > It would be not helpful for the qemu crash case you are concerned about. We want to use the guest state data to look into guest machine's image in the crasshed qemu. Thanks. HATAYAMA, Daisuke -- 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/4] Export offsets of VMCS fields as note information for kdump
On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote: > From: Avi Kivity > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information > for kdump > Date: Wed, 18 Apr 2012 14:56:39 +0300 > > > On 04/18/2012 12:49 PM, zhangyanfei wrote: > >> >> > >> > > >> > What type of resource? Can you give an example? > >> > > >> Sorry. No concrete example for now. > >> > >> We are developing this on a conservative policy and I have put the vmcs > >> processing > >> in a new module in patch set v2 as you required. The new module is > >> auto-loaded when > >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading > >> and unloading > >> this module will have no side effect on the running guests. > >> > >> And one thing I have to stress is that, we can see guest image as crash > >> dump from > >> guest machine's view if we have the vmcsinfo, this itself is useful. > > > > Why is it useful? Without a concrete example, it's hard to justify the > > code bloat. > > > > The reason why we want to retrieve guest machine's memory image as > crash dump is that then we can debug guest machine's status using > symbolic debugger such as gdb and crash utility. > > This is very useful. Please consider the situation where engineers are > forced to look into guest machine's memory image through qemu-kvm's > process core dump using gdb without any symbolic information. It's > very inefficient. I still don't follow. If qemu crashed, the values in guest registers are irrelevant. In what way can the help debug the qemu crash? -- 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/4] Export offsets of VMCS fields as note information for kdump
From: Avi Kivity Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump Date: Wed, 18 Apr 2012 14:56:39 +0300 > On 04/18/2012 12:49 PM, zhangyanfei wrote: >> >> >> > >> > What type of resource? Can you give an example? >> > >> Sorry. No concrete example for now. >> >> We are developing this on a conservative policy and I have put the vmcs >> processing >> in a new module in patch set v2 as you required. The new module is >> auto-loaded when >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading >> and unloading >> this module will have no side effect on the running guests. >> >> And one thing I have to stress is that, we can see guest image as crash dump >> from >> guest machine's view if we have the vmcsinfo, this itself is useful. > > Why is it useful? Without a concrete example, it's hard to justify the > code bloat. > The reason why we want to retrieve guest machine's memory image as crash dump is that then we can debug guest machine's status using symbolic debugger such as gdb and crash utility. This is very useful. Please consider the situation where engineers are forced to look into guest machine's memory image through qemu-kvm's process core dump using gdb without any symbolic information. It's very inefficient. Thanks. HATAYAMA, Daisuke -- 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/4] Export offsets of VMCS fields as note information for kdump
On 04/18/2012 04:47 PM, Nadav Har'El wrote: > On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets > of VMCS fields as note information for kdump": > > Right; they're also not required to be in memory at all - the processor > > can cache them, even for VMCSs that are not active at this time. > > Running VMXOFF at panic time can fix that, but you have to broadcast it > > to all processors, probably using NMI... > > I believe that a VMCLEAR ensures that the VMCS is written back to > memory. KVM uses this fact when migrating a VMCS between two separate > physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to > memory, and then VMPTRLD on the new CPU. > > So you don't need to VMXOFF, but do need to VMCLEAR. But there's still > the complication that you mention - you need to do the VMCLEAR on the right > processor... VMCLEAR only clears one VMCS; several may be cached by a processor at one time. Presumably VMXOFF flushes everything. -- 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/4] Export offsets of VMCS fields as note information for kdump
On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump": > Right; they're also not required to be in memory at all - the processor > can cache them, even for VMCSs that are not active at this time. > Running VMXOFF at panic time can fix that, but you have to broadcast it > to all processors, probably using NMI... I believe that a VMCLEAR ensures that the VMCS is written back to memory. KVM uses this fact when migrating a VMCS between two separate physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to memory, and then VMPTRLD on the new CPU. So you don't need to VMXOFF, but do need to VMCLEAR. But there's still the complication that you mention - you need to do the VMCLEAR on the right processor... -- Nadav Har'El| Wednesday, Apr 18 2012, n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |The only "intuitive" interface is the http://nadav.harel.org.il |nipple. After that, it's all learned. -- 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/4] Export offsets of VMCS fields as note information for kdump
On 04/17/2012 07:49 PM, Anthony Liguori wrote:
> On 04/17/2012 02:44 AM, Avi Kivity wrote:
>> 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: 127b0009 53434d56
>>> {...VMCS
>>> 1cba8d0: 4f464e49 4e4f495349564552
>>> INFOREVISION
>>> 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?
>
> Note that assuming that VMCS fields map to offsets within memory is
> not guaranteed to work for future processors.
>
> There is no guarantee that fields won't be compressed or stored with
> inverted bit ordering.
>
Right; they're also not required to be in memory at all - the processor
can cache them, even for VMCSs that are not active at this time.
Running VMXOFF at panic time can fix that, but you have to broadcast it
to all processors, probably using NMI...
Still, some information is better than nothing. What I doubt is whether
that information will ever be used.
--
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/4] Export offsets of VMCS fields as note information for kdump
On 04/18/2012 12:49 PM, zhangyanfei wrote: > >> > > > > What type of resource? Can you give an example? > > > Sorry. No concrete example for now. > > We are developing this on a conservative policy and I have put the vmcs > processing > in a new module in patch set v2 as you required. The new module is > auto-loaded when > the vmx cpufeature is detected and it depends on module kvm-intel. Loading > and unloading > this module will have no side effect on the running guests. > > And one thing I have to stress is that, we can see guest image as crash dump > from > guest machine's view if we have the vmcsinfo, this itself is useful. Why is it useful? Without a concrete example, it's hard to justify the code bloat. -- 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/4] Export offsets of VMCS fields as note information for kdump
于 2012年04月18日 16:24, Avi Kivity 写道: > On 04/18/2012 10:30 AM, zhangyanfei wrote: >>> >>> Okay. Do you expect it to help in debugging the crash? Did you have >>> cases where it would help? >>> >> >> Yes, I do expect it to help in debugging the crash. >> Looking into host machine's crash dump, if we figure out the fact that the >> crash >> had happend when some host's resource was requested and used by some guset >> machine. >> Then, we surely want to look into the situation from guest machine's view. >> >> > > What type of resource? Can you give an example? > Sorry. No concrete example for now. We are developing this on a conservative policy and I have put the vmcs processing in a new module in patch set v2 as you required. The new module is auto-loaded when the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading this module will have no side effect on the running guests. And one thing I have to stress is that, we can see guest image as crash dump from guest machine's view if we have the vmcsinfo, this itself is useful. 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/4] Export offsets of VMCS fields as note information for kdump
On 04/18/2012 10:30 AM, zhangyanfei wrote: > > > > Okay. Do you expect it to help in debugging the crash? Did you have > > cases where it would help? > > > > Yes, I do expect it to help in debugging the crash. > Looking into host machine's crash dump, if we figure out the fact that the > crash > had happend when some host's resource was requested and used by some guset > machine. > Then, we surely want to look into the situation from guest machine's view. > > What type of resource? Can you give an example? -- 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/4] Export offsets of VMCS fields as note information for kdump
于 2012年04月17日 18:59, Avi Kivity 写道:
> 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: 127b0009 53434d56 {...VMCS
1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
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?
>
Yes, I do expect it to help in debugging the crash.
Looking into host machine's crash dump, if we figure out the fact that the crash
had happend when some host's resource was requested and used by some guset
machine.
Then, we surely want to look into the situation from guest machine's view.
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/4] Export offsets of VMCS fields as note information for kdump
On 04/17/2012 02:44 AM, Avi Kivity wrote:
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: 127b0009 53434d56 {...VMCS
1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
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?
Note that assuming that VMCS fields map to offsets within memory is not
guaranteed to work for future processors.
There is no guarantee that fields won't be compressed or stored with inverted
bit ordering.
Regards,
Anthony Liguori
--
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/4] Export offsets of VMCS fields as note information for kdump
On 04/17/2012 02:25 PM, Wen Congyang wrote: > > > >> > >> 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... There are two cases. One case is where the problem was not caused directly by guest action, for example a segmentation fault in the block layer or the VNC server. In this case the guest registers are immaterial. The other case is where the problem was directly caused by guest action, for example an mmio write to a device register triggered an error. In this case kvm emulates the mmio instruction and returns KVM_EXIT_MMIO; it can be seen in the kvm_run page. The address/data pair is propagated by the qemu memory core all the way to the device callback. So the instruction and register contents are unneeded for debugging the crash. Is there a scenario where the guest registers help towards debugging a qemu crash? -- 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/4] Export offsets of VMCS fields as note information for kdump
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: 127b0009 53434d56 {...VMCS
1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
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: 127b0009 53434d56 {...VMCS
> >> 1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
> >> 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).
> Is this what you want?
>
Yes. I'm trying to understand if the feature would be useful in real life.
--
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/4] Export offsets of VMCS fields as note information for kdump
于 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: 127b0009 53434d56 {...VMCS
>> 1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
>> 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.
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.
Is this what you want?
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/4] Export offsets of VMCS fields as note information for kdump
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: 127b0009 53434d56 {...VMCS
> 1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
> 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?
--
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/4] Export offsets of VMCS fields as note information for kdump
On 04/11/2012 01:12 PM, zhangyanfei wrote: > > > >> 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. > > > > > > Seems excessive. Why do you want vmcs information in qemu cores? A > > qemu crash is very rarely related to kvm, let alone the vmcs. I > > understand that you may want it in a kernel core dump, though I've never > > needed to myself. Can you outline a case where this data was needed? > > > > If a qemu process comes to a fatal error that causes itself to be core dumped > by kernel, the running guest based on the qemu process will be included in > that > qemu core file. But with no vmcsinfo information in qemu core file, we could > not > get the guest's states(registers' values), then we could not make a complete > guest vmcore. We can't anyway. Many registers (GPRs except RSP, fpu) are not stored in the VMCS, but in kvm data structures. So for this case we'd want a kvm callback to execute (that would make it work cross vendor, too). > > >> 3. Dump guest image from the qemu-process core file into a vmcore. > > > > For this perhaps a different approach is better - modify the core dumper > > to call kvm to extract the relevant vmcs information into an elf note. > > This way there is no need to reconstruct the guest data from the > > offsets. It's also more reliable, since vmread can access cached fields > > that direct memory access cannot. > > > > Does this approach is a replacement for TODO 2 ? That is to say, when > generating > a qemu core by kernel core dumper, we could call kvm to extract the relevant > vmcs > information into an elf note instead of VMCSINFO and the whole vmcs regions. Yes. I'm not convinced it's important though. -- 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/4] Export offsets of VMCS fields as note information for kdump
于 2012年04月11日 18:21, Joerg Roedel 写道: > Hi, > > On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote: >> 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. > > Have you made sure this layout is the same on all uarchitectures that > implment VMX? > > > Joerg > The layout differs from each other in different VMCS revision identifiers. The VMCS revision identifier is contained at the first 32 bits of the VMCS region. And the VMCS revision identifiers may differ from different architectures. for example, there are two processors below: Processor 1: Intel(R) Xeon(R) CPU E7540 @ 2.00GHz with 24 cores REVISION_ID=e FIELD(PIN_BASED_VM_EXEC_CONTROL)=05540550 FIELD(CPU_BASED_VM_EXEC_CONTROL)=05440540 FIELD(SECONDARY_VM_EXEC_CONTROL)=054c0548 FIELD(VM_EXIT_CONTROLS) =057c0578 FIELD(VM_ENTRY_CONTROLS)=05940590 .. Processor 2: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz REVISION_ID=d FIELD(PIN_BASED_VM_EXEC_CONTROL)=01840180 FIELD(CPU_BASED_VM_EXEC_CONTROL)=01940190 FIELD(SECONDARY_VM_EXEC_CONTROL)=0fe40fe0 FIELD(VM_EXIT_CONTROLS) =01e401e0 FIELD(VM_ENTRY_CONTROLS)=03140310 The purpose to get the VMCSINFO of one architecture is for guest debugging that was running on the same architecture, so there is no problem the layouts differ from different architectures. 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/4] Export offsets of VMCS fields as note information for kdump
On 04/11/2012 01:21 PM, Joerg Roedel wrote: > Hi, > > On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote: > > 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. > > Have you made sure this layout is the same on all uarchitectures that > implment VMX? He's determining the layout at runtime. It should even work with kvm's vmx implementation. It's vulnerable to two issues: - fields that are cached in the processor and not flushed to memory (perhaps just make sure to VMXOFF before dumping memory) - fields that are encoded differently in memory than VMREAD/VMWRITE -- 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/4] Export offsets of VMCS fields as note information for kdump
Hi, On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote: > 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. Have you made sure this layout is the same on all uarchitectures that implment VMX? Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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/4] Export offsets of VMCS fields as note information for kdump
于 2012年04月11日 16:56, 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: 127b0009 53434d56 {...VMCS
>> 1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
>> 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
>> ..
>
> Would be nicer to have a simple binary encoding instead
> of this.
Agreed.
>
>> 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.
>
>
> Seems excessive. Why do you want vmcs information in qemu cores? A
> qemu crash is very rarely related to kvm, let alone the vmcs. I
> understand that you may want it in a kernel core dump, though I've never
> needed to myself. Can you outline a case where this data was needed?
>
If a qemu process comes to a fatal error that causes itself to be core dumped
by kernel, the running guest based on the qemu process will be included in that
qemu core file. But with no vmcsinfo information in qemu core file, we could not
get the guest's states(registers' values), then we could not make a complete
guest vmcore.
>> 3. Dump guest image from the qemu-process core file into a vmcore.
>
> For this perhaps a different approach is better - modify the core dumper
> to call kvm to extract the relevant vmcs information into an elf note.
> This way there is no need to reconstruct the guest data from the
> offsets. It's also more reliable, since vmread can access cached fields
> that direct memory access cannot.
>
Does this approach is a replacement for TODO 2 ? That is to say, when generating
a qemu core by kernel core dumper, we could call kvm to extract the relevant
vmcs
information into an elf note instead of VMCSINFO and the whole vmcs regions.
--
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/4] Export offsets of VMCS fields as note information for kdump
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: 127b0009 53434d56 {...VMCS
> 1cba8d0: 4f464e49 4e4f495349564552 INFOREVISION
> 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
> ..
Would be nicer to have a simple binary encoding instead
of this.
> 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.
Seems excessive. Why do you want vmcs information in qemu cores? A
qemu crash is very rarely related to kvm, let alone the vmcs. I
understand that you may want it in a kernel core dump, though I've never
needed to myself. Can you outline a case where this data was needed?
> 3. Dump guest image from the qemu-process core file into a vmcore.
For this perhaps a different approach is better - modify the core dumper
to call kvm to extract the relevant vmcs information into an elf note.
This way there is no need to reconstruct the guest data from the
offsets. It's also more reliable, since vmread can access cached fields
that direct memory access cannot.
--
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
