public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Justin Cinkelj <justin.cinkelj@xlab.si>
To: Mark Wielaard <mark@klomp.org>, elfutils-devel@sourceware.org
Subject: Re: get backtrace of KVM VM from host
Date: Tue, 22 May 2018 15:07:00 -0000	[thread overview]
Message-ID: <57cf8bac-adbc-d3d6-ec86-be5e03d82aac@xlab.si> (raw)
In-Reply-To: <1526997887.2911.10.camel@klomp.org>

Something like that was suggested at KVM devel list too. I was able to 
get an useful backtrace for a trivial VM (a single ELF file, VM code 
runs directly from (virtual) physical memory). Well, that was more to 
learn a bit about elfutils than anything else. A more realistic VM will 
be more difficult, I guess.

Justin

On 05/22/2018 04:04 PM, Mark Wielaard wrote:
> Hi,
>
> On Mon, 2018-05-21 at 10:26 +0200, Justin Cinkelj wrote:
>> Is it possible to get stack backtrace into KVM VM from the host side?
>> So
>> if I run './stack -p PID' (stack from elfutilfs
>> https://sourceware.org/elfutils/), I get backtrace of some process. I
>> would like to do the same for VM. I can assume VM will run only a kernel
>> (a unikernel, like OSv or IncludeOS), so most/all debug symbols will be
>> there in a single file, and at least IncludeOS doesnt load any code
>> beside its own kernel.
>>
>> I did notice KVM_GET_REGS and KVM_SET_MEMORY_REGION, and at least for
>>> trivial examples (like https://github.com/dpw/kvm-hello-world) this
>> provides enough information to track which code was loaded into VM,
>> observe current stack content and registers. I can only guess much more
>> work is required to get similar result with qemu-kvm. Hence I'm asking
>> if this is already implemented.
> Providing the registers and memory view inside the KVM VM would be the
> first step. elfutils would also need to know the memory/ELF process
> layout. For a normal process that would come from e.g. /proc/pid/maps.
> Using such a layout eu-stack would then be able to find the unwind
> tables and symbols associated with a particular address.
>
> I believe qemu already has an gdb stub that gdb can use to get at the
> registers, memory and process layout. Maybe you could adapt that
> provide the information needed.
>
> Cheers,
>
> Mark

      reply	other threads:[~2018-05-22 15:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21  8:27 Justin Cinkelj
2018-05-22 14:05 ` Mark Wielaard
2018-05-22 15:07   ` Justin Cinkelj [this message]

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=57cf8bac-adbc-d3d6-ec86-be5e03d82aac@xlab.si \
    --to=justin.cinkelj@xlab.si \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).