Message-ID: <4F93D64B.50803@redhat.com>
Date:	Sun, 22 Apr 2012 12:58:35 +0300
From:	Avi Kivity <avi@...hat.com>
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
CC:	dzickus@...hat.com, luto@....edu, gregkh@...e.de,
	kvm@...r.kernel.org, joerg.roedel@....com, mtosatti@...hat.com,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	paul.gortmaker@...driver.com, zhangyanfei@...fujitsu.com,
	ebiederm@...ssion.com, ludwig.nussel@...e.de
Subject: 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 <avi@...hat.com>
> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists