All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] optionally specify vm stop message
Date: Fri, 16 Jan 2009 17:36:27 +0100	[thread overview]
Message-ID: <4970B78B.8070900@siemens.com> (raw)
In-Reply-To: <4970B582.7040009@codemonkey.ws>

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>>>  Also non zero reasons a handled differently by vm_stop. Don't know
>>>> why.
>>>>         
>>> It's an ugly hack for gdbstub.  It notifies gdb when a breakpoint
>>> occurs.  We have far too many state tracking mechanisms.  Anyway, gdb
>>> can pass something like VM_STOP_BP and that can be used to trigger the
>>> callback.
>>>     
>>
>> It's not only used for breakpoints but any stop condition that should be
>> reported to the gdb frontend (so far: EXCP_DEBUG and EXCP_INTERRUPT).
>> Not sure, though, how to deal with ENOSPC - it's not a guest fault, it's
>> a host problem. From that POV, gdb should not receive it.
>>   
> 
> We already have a vm_change_state_handler that is invoked whenever a
> guest starts running or stops running.  gdb should be able to use that
> and look at env->exception_index, no?

I don't think env->exception_index is set when you issue "stop" from the
monitor, e.g. Moreover, that would be an ugly (out-of-band) API as well.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

  reply	other threads:[~2009-01-16 16:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-15 10:37 [Qemu-devel] [PATCH] optionally specify vm stop message Gleb Natapov
2009-01-15 20:46 ` Anthony Liguori
2009-01-16  7:14   ` Gleb Natapov
2009-01-16 15:26     ` Anthony Liguori
2009-01-16 16:24       ` [Qemu-devel] " Jan Kiszka
2009-01-16 16:27         ` Anthony Liguori
2009-01-16 16:36           ` Jan Kiszka [this message]
2009-01-16 16:45             ` Jan Kiszka
2009-01-16 17:02               ` Jan Kiszka
2009-01-16 17:14                 ` Anthony Liguori

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=4970B78B.8070900@siemens.com \
    --to=jan.kiszka@siemens.com \
    --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.