All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Raasch <sraasch@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: Extracting PC information from QEMU/KVM during single-step
Date: Thu, 24 Jun 2021 12:08:49 -0500	[thread overview]
Message-ID: <CA+5M2MDnOEvpmAn3Vhc_crj7prR6pDymTgtkFYgyh1HXJvyddA@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8eADzVVMVZHaHBC9Lm09aVvC5Wwj-q7nLkKoRUn3vS5A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

Understood with your KVM/TCG snapshot comment. I thought it was worth a try.

NOTE: I do not yet understand how gdb interacts with the virtual machine. I
have experience with GDB, but only at a linux app-debug level. I don't grok
how gdb on a linux host works with QEMU running a windows guest.
My *assumption* is that the VM continues to run while an app is being
debugged with GDB can be stopped, stepped, etc. If this is the case, I
would expect that the VM's sense of time will continue to move forward
while the app is paused. This would be an issue for my time-sensitive app.

If I slow down the entire QEMU system with my hacks, then my expectation is
that the time for both the VM and the app will slow down similarly (if I
decouple the VM time from real-world time using the -rtc command-line
argument).

So...
   1) Are my assumptions close?
   2) Can someone point me to information on using gdb with QEMU/KVM?

Thanks!
-S




On Thu, Jun 24, 2021 at 11:23 AM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Wed, 23 Jun 2021 at 22:10, Steven Raasch <sraasch@gmail.com> wrote:
> > I have used KVM to create a snapshot of a windows-10 guest running a
> graphics-intensive app. The *original* issue is that the app does not
> execute correctly when re-started from the snapshot using TCG (it doesn't
> crash, but it doesn't run correctly, either).
>
> I'm not sure that taking a snapshot with KVM and then resuming under TCG
> is really tested. So I'm not very surprised that it doesn't work.
>
> > I'm setting DEBUG & single-step modes by calling cpu_single_step() from
> the top of kvm_vcpu_thread_fn().
> > in kvm_cpu_exec() I wait until I get a KVM_EXIT_DEBUG signal before
> logging the instruction.
>
> If your app can cope with the slowdown involved in taking a VM exit
> after every instruction (which will be massive), then it can probably
> also handle the extra overhead on top of that of the gdbstub communication
> protocol. So it's probably simplest just to connect to QEMU's gdbstub and
> do the single-stepping that way.
>
> The other approach to this would be to see if intel's perf monitor
> stuff (which I know nothing about) has some kind of execution-trace
> capture support and if that works when passing through the PMU to a
> KVM guest.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 2955 bytes --]

  reply	other threads:[~2021-06-24 17:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 20:14 Extracting PC information from QEMU/KVM during single-step Steven Raasch
2021-06-24  1:45 ` Alexander Bulekov
2021-06-24 13:49   ` Steven Raasch
2021-06-24 14:41     ` Alexander Bulekov
2021-06-24 16:22 ` Peter Maydell
2021-06-24 17:08   ` Steven Raasch [this message]
2021-06-24 18:51     ` Peter Maydell
2021-06-24 19:36       ` Steven Raasch

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=CA+5M2MDnOEvpmAn3Vhc_crj7prR6pDymTgtkFYgyh1HXJvyddA@mail.gmail.com \
    --to=sraasch@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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 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.