qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] optionally specify vm stop message
Date: Fri, 16 Jan 2009 10:27:46 -0600	[thread overview]
Message-ID: <4970B582.7040009@codemonkey.ws> (raw)
In-Reply-To: <4970B4A1.3000106@siemens.com>

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?

Regards,

Anthony Liguori

> Nevertheless, gdb_vm_stopped should better do the filtering, not the
> caller of vm_stop by passing 0 for "any other reason gdb should be
> bothered with".
>
> Jan
>
>   

  reply	other threads:[~2009-01-16 16:28 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 [this message]
2009-01-16 16:36           ` Jan Kiszka
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=4970B582.7040009@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --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 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 NNTP newsgroup(s).