All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: kvm-devel@lists.sourceforge.net,
	kvm-ppc-devel@lists.sourceforge.net, jyoung5@us.ibm.com
Subject: Re: [kvm-ppc-devel] [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST
Date: Wed, 14 May 2008 19:10:06 +0000	[thread overview]
Message-ID: <482B390E.7040004@web.de> (raw)
In-Reply-To: <200805141325.32231.hollisb@us.ibm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1778 bytes --]

Hollis Blanchard wrote:
> On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
>> So gdb on power relies only on those few hw-breakpoints? With x86 you
>> can perfectly run gdb (with soft BPs) in parallel with the gdbstub
>> (currently based on hw-BPs, but the same would be true for soft-BPs
>> inserted by the gdbstub).
> 
> GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It 
> does not rely on the hardware breakpoints.
> 
> It gets a little more complicated when you involve a GDB stub. IIRC, GDB will 
> ask the stub to set the breakpoint, and if the stub doesn't support it, GDB 
> will fall back to overwriting the instructions in memory. Does the Qemu GDB 
> stub advertise breakpoint support?

Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something
even gdbserver does not do! It just handles watchpoints (Z2..4).

> 
> If not, the only support needed in KVM would be to send all debug interrupts 
> to qemu, and allow qemu to send them back down for in-guest breakpoints.
> 

Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's
kernel side should not yet inform QEMU about soft-BP exceptions. But in
theory, this should be easily fixable (or is already the case for other
archs). And it would safe us from keeping track of N software
breakpoints, where N could even become larger than 32, the current
hardcoded limit for plain QEMU. :)

Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is
insufficient: We need a return channel for the debug register state
(specifically to figure out details about hit watchpoints). I'm now
favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us
to write _and_ read-back the suggested data structure.

Jan


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 230 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 170 bytes --]

_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: kvm-devel@lists.sourceforge.net,
	kvm-ppc-devel@lists.sourceforge.net, jyoung5@us.ibm.com
Subject: Re: [RFC] Reworking KVM_DEBUG_GUEST
Date: Wed, 14 May 2008 21:10:06 +0200	[thread overview]
Message-ID: <482B390E.7040004@web.de> (raw)
In-Reply-To: <200805141325.32231.hollisb@us.ibm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1778 bytes --]

Hollis Blanchard wrote:
> On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
>> So gdb on power relies only on those few hw-breakpoints? With x86 you
>> can perfectly run gdb (with soft BPs) in parallel with the gdbstub
>> (currently based on hw-BPs, but the same would be true for soft-BPs
>> inserted by the gdbstub).
> 
> GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It 
> does not rely on the hardware breakpoints.
> 
> It gets a little more complicated when you involve a GDB stub. IIRC, GDB will 
> ask the stub to set the breakpoint, and if the stub doesn't support it, GDB 
> will fall back to overwriting the instructions in memory. Does the Qemu GDB 
> stub advertise breakpoint support?

Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something
even gdbserver does not do! It just handles watchpoints (Z2..4).

> 
> If not, the only support needed in KVM would be to send all debug interrupts 
> to qemu, and allow qemu to send them back down for in-guest breakpoints.
> 

Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's
kernel side should not yet inform QEMU about soft-BP exceptions. But in
theory, this should be easily fixable (or is already the case for other
archs). And it would safe us from keeping track of N software
breakpoints, where N could even become larger than 32, the current
hardcoded limit for plain QEMU. :)

Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is
insufficient: We need a return channel for the debug register state
(specifically to figure out details about hit watchpoints). I'm now
favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us
to write _and_ read-back the suggested data structure.

Jan


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 230 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

  reply	other threads:[~2008-05-14 19:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-12 11:34 [RFC] Reworking KVM_DEBUG_GUEST Jan Kiszka
2008-05-14 15:12 ` Jerone Young
2008-05-14 15:28   ` Jan Kiszka
2008-05-14 15:55     ` Jerone Young
2008-05-14 18:25     ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-05-14 18:25       ` Hollis Blanchard
2008-05-14 19:10       ` Jan Kiszka [this message]
2008-05-14 19:10         ` Jan Kiszka
2008-05-14 19:33         ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-05-14 19:33           ` Hollis Blanchard
2008-05-14 19:49           ` [kvm-ppc-devel] [kvm-devel] " Jan Kiszka
2008-05-14 19:49             ` Jan Kiszka
2008-05-14 21:06             ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-05-14 21:06               ` Hollis Blanchard
2008-05-14 21:11               ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-05-14 21:11                 ` [kvm-ppc-devel] " Hollis Blanchard
2008-05-14 21:13                 ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-05-14 21:13                   ` [kvm-ppc-devel] " Hollis Blanchard
2008-05-15  7:47 ` Avi Kivity

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=482B390E.7040004@web.de \
    --to=jan.kiszka@web.de \
    --cc=hollisb@us.ibm.com \
    --cc=jyoung5@us.ibm.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=kvm-ppc-devel@lists.sourceforge.net \
    /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.