Software breakpoint in kvmppc guest debug

Software breakpoint in kvmppc guest debug

[Liu Yu-B13201]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 871 bytes --]


Hello all,

Software breakpoint is a instruction which should make guest exit.
We replace guest code with software breakpoint instruction so that we can stop at anywhere we want.

In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint.
Seem this was not good, since (sc 64) maybe defined in future.
also this instruction has uncertain effective on E.HV platform such as e500mc.

Another choice is to use trap instruction.
In order to distinguish between real guest trap and software breakpoint trap.
It's needed to trace software breakpoint addressed in kernel,
and we need to create ioctls to add/remove software point.

So guys, which way should we choose?
Or is there any other better idea?

Thanks,
Yu
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¤¾oé¥ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Software breakpoint in kvmppc guest debug

[Alexander Graf]

Hi Yu,

On 09.11.2010, at 04:40, Liu Yu-B13201 wrote:

> 
> Hello all,
> 
> Software breakpoint is a instruction which should make guest exit.
> We replace guest code with software breakpoint instruction so that we can stop at anywhere we want.
> 
> In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint.
> Seem this was not good, since (sc 64) maybe defined in future.

That's always the case with overloading instructions :).

> also this instruction has uncertain effective on E.HV platform such as e500mc.

Not sure if the hardware or other hypervisors break the spec, but according to 2.06 page 908 only LEV=0 and LEV=1 are defined.

> Another choice is to use trap instruction.
> In order to distinguish between real guest trap and software breakpoint trap.
> It's needed to trace software breakpoint addressed in kernel,
> and we need to create ioctls to add/remove software point.

That's another way to do this, yes. X86 also uses the normal trap instruction (int 3). Once the first breakpoint is set from external gdb, traps always go to gdb, even if they were not used for software breakpoints.

See target-i386/kvm.c:kvm_arch_update_guest_debug() and kvm-all.c:kvm_update_guest_debug().

I'd say we should model it the same way for now. If possible, the real solution for later would be to use hardware breakpoints using IAC registers.


Alex

Re: Software breakpoint in kvmppc guest debug

[Scott Wood]

On Tue, 9 Nov 2010 13:14:47 +0100
Alexander Graf <agraf@suse.de> wrote:

> On 09.11.2010, at 04:40, Liu Yu-B13201 wrote:
> 
> > Software breakpoint is a instruction which should make guest exit.
> > We replace guest code with software breakpoint instruction so that we can stop at anywhere we want.
> > 
> > In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint.
> > Seem this was not good, since (sc 64) maybe defined in future.
> 
> That's always the case with overloading instructions :).
> 
> > also this instruction has uncertain effective on E.HV platform such as e500mc.
> 
> Not sure if the hardware or other hypervisors break the spec, but according to 2.06 page 908 only LEV=0 and LEV=1 are defined.

Does it say whether undefined values trap?  Maybe it only looks at the
low bit of LEV, or checks != 0, etc.

> > Another choice is to use trap instruction.
> > In order to distinguish between real guest trap and software breakpoint trap.
> > It's needed to trace software breakpoint addressed in kernel,
> > and we need to create ioctls to add/remove software point.
> 
> That's another way to do this, yes. X86 also uses the normal trap instruction (int 3). Once the first breakpoint is set from external gdb, traps always go to gdb, even if they were not used for software breakpoints.
> 
> See target-i386/kvm.c:kvm_arch_update_guest_debug() and kvm-all.c:kvm_update_guest_debug().
> 
> I'd say we should model it the same way for now. 

I agree.

> If possible, the real solution for later would be to use hardware breakpoints using IAC registers.

IAC has its own issues, as they're a limited resource -- made worse by
the possibility of the guest wanting to use them.

There are also some fun issues regarding MSR[DE] with E.HV --
there are two modes, either the guest can control it directly (and shut
down KVM's debug events) or the guest does not have access to debug
resources at all and guest changes to MSR[DE] are ignored.  MSR writes
never trap.

-Scott

Re: Software breakpoint in kvmppc guest debug

[Alexander Graf]

On 09.11.2010, at 17:36, Scott Wood wrote:

> On Tue, 9 Nov 2010 13:14:47 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
>> On 09.11.2010, at 04:40, Liu Yu-B13201 wrote:
>> 
>>> Software breakpoint is a instruction which should make guest exit.
>>> We replace guest code with software breakpoint instruction so that we can stop at anywhere we want.
>>> 
>>> In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint.
>>> Seem this was not good, since (sc 64) maybe defined in future.
>> 
>> That's always the case with overloading instructions :).
>> 
>>> also this instruction has uncertain effective on E.HV platform such as e500mc.
>> 
>> Not sure if the hardware or other hypervisors break the spec, but according to 2.06 page 908 only LEV=0 and LEV=1 are defined.
> 
> Does it say whether undefined values trap?  Maybe it only looks at the
> low bit of LEV, or checks != 0, etc.

It doesn't mentioned undefined values. It only mentions LEV=0 and LEV=1. But I don't like the idea of hard overloading a specific LEV value either way :). I'd rather use an undefined instruction for it.

> 
>>> Another choice is to use trap instruction.
>>> In order to distinguish between real guest trap and software breakpoint trap.
>>> It's needed to trace software breakpoint addressed in kernel,
>>> and we need to create ioctls to add/remove software point.
>> 
>> That's another way to do this, yes. X86 also uses the normal trap instruction (int 3). Once the first breakpoint is set from external gdb, traps always go to gdb, even if they were not used for software breakpoints.
>> 
>> See target-i386/kvm.c:kvm_arch_update_guest_debug() and kvm-all.c:kvm_update_guest_debug().
>> 
>> I'd say we should model it the same way for now. 
> 
> I agree.
> 
>> If possible, the real solution for later would be to use hardware breakpoints using IAC registers.
> 
> IAC has its own issues, as they're a limited resource -- made worse by
> the possibility of the guest wanting to use them.

Same thing for x86, but somehow it works out ;-).

> There are also some fun issues regarding MSR[DE] with E.HV --
> there are two modes, either the guest can control it directly (and shut
> down KVM's debug events) or the guest does not have access to debug
> resources at all and guest changes to MSR[DE] are ignored.  MSR writes
> never trap.

There are no hypervisor privileged debug registers?


Alex

Re: Software breakpoint in kvmppc guest debug

[Hollis Blanchard]

On 11/09/2010 08:50 AM, Alexander Graf wrote:
> On 09.11.2010, at 17:36, Scott Wood wrote:
>> >  On Tue, 9 Nov 2010 13:14:47 +0100
>> >  Alexander Graf<agraf@suse.de>  wrote:
>>> >>  On 09.11.2010, at 04:40, Liu Yu-B13201 wrote:
>>>> >>>  Software breakpoint is a instruction which should make guest exit.
>>>> >>>  We replace guest code with software breakpoint instruction so that we can stop at anywhere we want.
>>>> >>>  
>>>> >>>  In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint.
>>>> >>>  Seem this was not good, since (sc 64) maybe defined in future.
>>> >>  
>>> >>  That's always the case with overloading instructions :).
>>> >>  
>>>> >>>  also this instruction has uncertain effective on E.HV platform such as e500mc.
>>> >>  
>>> >>  Not sure if the hardware or other hypervisors break the spec, but according to 2.06 page 908 only LEV=0 and LEV=1 are defined.
>> >  
>> >  Does it say whether undefined values trap?  Maybe it only looks at the
>> >  low bit of LEV, or checks != 0, etc.
> It doesn't mentioned undefined values. It only mentions LEV=0 and LEV=1. But I don't like the idea of hard overloading a specific LEV value either way :). I'd rather use an undefined instruction for it.
Who's to say that undefined instruction will remain undefined in the 
future? It amounts to the same problem.

Although in other ways the ISA benefits from a great deal of foresight, 
as far as I remember this particular issue isn't addressed.

Hollis Blanchard
Mentor Graphics, Embedded Systems Division

Re: Software breakpoint in kvmppc guest debug

[Alexander Graf]

On 09.11.2010, at 18:00, Hollis Blanchard wrote:

> On 11/09/2010 08:50 AM, Alexander Graf wrote:
>> On 09.11.2010, at 17:36, Scott Wood wrote:
>>> >  On Tue, 9 Nov 2010 13:14:47 +0100
>>> >  Alexander Graf<agraf@suse.de>  wrote:
>>>> >>  On 09.11.2010, at 04:40, Liu Yu-B13201 wrote:
>>>>> >>>  Software breakpoint is a instruction which should make guest exit.
>>>>> >>>  We replace guest code with software breakpoint instruction so that we can stop at anywhere we want.
>>>>> >>>  >>>  In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint.
>>>>> >>>  Seem this was not good, since (sc 64) maybe defined in future.
>>>> >>  >>  That's always the case with overloading instructions :).
>>>> >>  
>>>>> >>>  also this instruction has uncertain effective on E.HV platform such as e500mc.
>>>> >>  >>  Not sure if the hardware or other hypervisors break the spec, but according to 2.06 page 908 only LEV=0 and LEV=1 are defined.
>>> >  >  Does it say whether undefined values trap?  Maybe it only looks at the
>>> >  low bit of LEV, or checks != 0, etc.
>> It doesn't mentioned undefined values. It only mentions LEV=0 and LEV=1. But I don't like the idea of hard overloading a specific LEV value either way :). I'd rather use an undefined instruction for it.
> Who's to say that undefined instruction will remain undefined in the future? It amounts to the same problem.

Oh sorry if that sounded as if I wanted to see an undefined instruction being used. I was trying to make the point that using an undefined instruction is very bad and thus should not happen. So using sc 64 sounds about as bad to me.

Now, if we can get away with not using an undefined instruction (be it sc 64 or trap) I don't know. I'm not even sure we can get away with trap. Basically, WARN_ON should also trigger a trap, so you'd end up in gdb for that when having a breakpoint defined.

We should really include Jan in the discussion. He's the debug framework expert in qemu and kvm and maybe has some ideas and plans on where to drive the whole thing.

> Although in other ways the ISA benefits from a great deal of foresight, as far as I remember this particular issue isn't addressed.

:(


Alex

Re: Software breakpoint in kvmppc guest debug

[Scott Wood]

On Tue, 9 Nov 2010 18:14:31 +0100
Alexander Graf <agraf@suse.de> wrote:

> Now, if we can get away with not using an undefined instruction (be it sc 64 or trap) I don't know. I'm not even sure we can get away with trap. Basically, WARN_ON should also trigger a trap, so you'd end up in gdb for that when having a breakpoint defined.

There'd need to be a way for qemu/gdb to have KVM reflect the exception
to the guest if it doesn't have a breakpoint on file for that address.

-Scott

Re: Software breakpoint in kvmppc guest debug

[Scott Wood]

On Tue, 9 Nov 2010 17:50:12 +0100
Alexander Graf <agraf@suse.de> wrote:

> > There are also some fun issues regarding MSR[DE] with E.HV --
> > there are two modes, either the guest can control it directly (and shut
> > down KVM's debug events) or the guest does not have access to debug
> > resources at all and guest changes to MSR[DE] are ignored.  MSR writes
> > never trap.
> 
> There are no hypervisor privileged debug registers?

The debug registers themselves are hv privileged, but MSR[DE] is
special.  The guest can be allowed or not to change it, based on
MSRP[DEP], but it can't be trapped.

So if you want both hv and guest to share the debug resources, the
guest needs to be well-behaved about when it disables MSR[DE].  It
also needs to not depend on DSRR0/1 retaining their values when MSR[DE]
is set.

-Scott

Re: Software breakpoint in kvmppc guest debug

[Alexander Graf]

On 09.11.2010, at 19:17, Scott Wood wrote:

> On Tue, 9 Nov 2010 18:14:31 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
>> Now, if we can get away with not using an undefined instruction (be it sc 64 or trap) I don't know. I'm not even sure we can get away with trap. Basically, WARN_ON should also trigger a trap, so you'd end up in gdb for that when having a breakpoint defined.
> 
> There'd need to be a way for qemu/gdb to have KVM reflect the exception
> to the guest if it doesn't have a breakpoint on file for that address.

Yes, but that piece is missing for every KVM target right now. I'd like to see something generic emerge here that we can reuse across different architectures :).

Trap seems very tricky too though. According to page 1082 of the 2.06 spec, trap can issue a debug or a program interrupt depending on MSR_DE. I don't see any mentioning in the spec that we intercept program or debug interrupts. So I guess we'd have to override the offset vectors and handle _every_ interrupt ourselves. Bleks.


Alex

Re: Software breakpoint in kvmppc guest debug

[Scott Wood]

On Tue, 9 Nov 2010 19:26:25 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 09.11.2010, at 19:17, Scott Wood wrote:
> 
> > On Tue, 9 Nov 2010 18:14:31 +0100
> > Alexander Graf <agraf@suse.de> wrote:
> > 
> >> Now, if we can get away with not using an undefined instruction (be it sc 64 or trap) I don't know. I'm not even sure we can get away with trap. Basically, WARN_ON should also trigger a trap, so you'd end up in gdb for that when having a breakpoint defined.
> > 
> > There'd need to be a way for qemu/gdb to have KVM reflect the exception
> > to the guest if it doesn't have a breakpoint on file for that address.
> 
> Yes, but that piece is missing for every KVM target right now. I'd like to see something generic emerge here that we can reuse across different architectures :).

We should try to define something that will make sense on other
architectures, to whatever extent is practical -- but that doesn't mean
we need to wait for them to act first. :-)

> Trap seems very tricky too though. According to page 1082 of the 2.06 spec, trap can issue a debug or a program interrupt depending on MSR_DE. I don't see any mentioning in the spec that we intercept program or debug interrupts. So I guess we'd have to override the offset vectors and handle _every_ interrupt ourselves. Bleks.

Program and debug interrupts always go to the hypervisor.  Only the
exceptions for which GIVORs are defined (DSI, ISI, external IRQ,
syscall, TLB miss) can go directly to the guest, and even those
are generally optional based on EPCR.

-Scott

Re: Software breakpoint in kvmppc guest debug

[Alexander Graf]

On 09.11.2010, at 19:43, Scott Wood wrote:

> On Tue, 9 Nov 2010 19:26:25 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
>> 
>> On 09.11.2010, at 19:17, Scott Wood wrote:
>> 
>>> On Tue, 9 Nov 2010 18:14:31 +0100
>>> Alexander Graf <agraf@suse.de> wrote:
>>> 
>>>> Now, if we can get away with not using an undefined instruction (be it sc 64 or trap) I don't know. I'm not even sure we can get away with trap. Basically, WARN_ON should also trigger a trap, so you'd end up in gdb for that when having a breakpoint defined.
>>> 
>>> There'd need to be a way for qemu/gdb to have KVM reflect the exception
>>> to the guest if it doesn't have a breakpoint on file for that address.
>> 
>> Yes, but that piece is missing for every KVM target right now. I'd like to see something generic emerge here that we can reuse across different architectures :).
> 
> We should try to define something that will make sense on other
> architectures, to whatever extent is practical -- but that doesn't mean
> we need to wait for them to act first. :-)

Oh, I agree. I'm saying we should have Jan in the discussion :).

>> Trap seems very tricky too though. According to page 1082 of the 2.06 spec, trap can issue a debug or a program interrupt depending on MSR_DE. I don't see any mentioning in the spec that we intercept program or debug interrupts. So I guess we'd have to override the offset vectors and handle _every_ interrupt ourselves. Bleks.
> 
> Program and debug interrupts always go to the hypervisor.  Only the
> exceptions for which GIVORs are defined (DSI, ISI, external IRQ,
> syscall, TLB miss) can go directly to the guest, and even those
> are generally optional based on EPCR.

Ah, so it's a positive list. I guess I missed that part :). Thanks for the clarification.

So making it a trap instruction for now should be ok. Let's align the code to the same x86 looks like for now. In the meanwhile, let's discuss with Jan on how to get a list of patched IPs into the kernel and implement that on top of the code we'll have aligned with x86 by then :).


Alex

RE: Software breakpoint in kvmppc guest debug

[Yoder Stuart-B08248]

> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org
[mailto:kvm-ppc-owner@vger.kernel.org]
> On Behalf Of Alexander Graf
> Sent: Tuesday, November 09, 2010 12:50 PM
> To: Wood Scott-B07421
> Cc: Hollis Blanchard; Liu Yu-B13201; kvm-ppc@vger.kernel.org; Jan
Kiszka
> Subject: Re: Software breakpoint in kvmppc guest debug
> 
> 
> On 09.11.2010, at 19:43, Scott Wood wrote:
> 
> > On Tue, 9 Nov 2010 19:26:25 +0100
> > Alexander Graf <agraf@suse.de> wrote:
> >
> >>
> >> On 09.11.2010, at 19:17, Scott Wood wrote:
> >>
> >>> On Tue, 9 Nov 2010 18:14:31 +0100
> >>> Alexander Graf <agraf@suse.de> wrote:
> >>>
> >>>> Now, if we can get away with not using an undefined instruction
(be it
> sc 64 or trap) I don't know. I'm not even sure we can get away with
trap.
> Basically, WARN_ON should also trigger a trap, so you'd end up in gdb
for
> that when having a breakpoint defined.
> >>>
> >>> There'd need to be a way for qemu/gdb to have KVM reflect the
> >>> exception to the guest if it doesn't have a breakpoint on file for
that
> address.
> >>
> >> Yes, but that piece is missing for every KVM target right now. I'd
like
> to see something generic emerge here that we can reuse across
different
> architectures :).
> >
> > We should try to define something that will make sense on other
> > architectures, to whatever extent is practical -- but that doesn't
> > mean we need to wait for them to act first. :-)
> 
> Oh, I agree. I'm saying we should have Jan in the discussion :).
> 
> >> Trap seems very tricky too though. According to page 1082 of the
2.06
> spec, trap can issue a debug or a program interrupt depending on
MSR_DE. I
> don't see any mentioning in the spec that we intercept program or
debug
> interrupts. So I guess we'd have to override the offset vectors and
handle
> _every_ interrupt ourselves. Bleks.
> >
> > Program and debug interrupts always go to the hypervisor.  Only the
> > exceptions for which GIVORs are defined (DSI, ISI, external IRQ,
> > syscall, TLB miss) can go directly to the guest, and even those are
> > generally optional based on EPCR.
> 
> Ah, so it's a positive list. I guess I missed that part :). Thanks for
the
> clarification.
> 
> So making it a trap instruction for now should be ok. Let's align the
code
> to the same x86 looks like for now. In the meanwhile, let's discuss
with
> Jan on how to get a list of patched IPs into the kernel and implement
that
> on top of the code we'll have aligned with x86 by then :).

What about using the ehpriv instruction (defined in 2.06)?
We could define a unique "qemu software breakpoint", and the
hypervisor's ehpriv handler will be able to easily distinguish them.

On e500v2, this would be an illegal instruction.

We don't need to worry about a conflict with future opcodes
and it seems like the whole point of ehpriv being defined-- to let
a hypervisor define special opcodes for stuff like this.

If we use trap, we will need the list of patched IPs in 
the kernel.   ehpriv avoids the need for that.

Stuart

Re: Software breakpoint in kvmppc guest debug

[Alexander Graf]

On 10.11.2010, at 04:31, Yoder Stuart-B08248 wrote:

> 
> 
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org
> [mailto:kvm-ppc-owner@vger.kernel.org]
>> On Behalf Of Alexander Graf
>> Sent: Tuesday, November 09, 2010 12:50 PM
>> To: Wood Scott-B07421
>> Cc: Hollis Blanchard; Liu Yu-B13201; kvm-ppc@vger.kernel.org; Jan
> Kiszka
>> Subject: Re: Software breakpoint in kvmppc guest debug
>> 
>> 
>> On 09.11.2010, at 19:43, Scott Wood wrote:
>> 
>>> On Tue, 9 Nov 2010 19:26:25 +0100
>>> Alexander Graf <agraf@suse.de> wrote:
>>> 
>>>> 
>>>> On 09.11.2010, at 19:17, Scott Wood wrote:
>>>> 
>>>>> On Tue, 9 Nov 2010 18:14:31 +0100
>>>>> Alexander Graf <agraf@suse.de> wrote:
>>>>> 
>>>>>> Now, if we can get away with not using an undefined instruction
> (be it
>> sc 64 or trap) I don't know. I'm not even sure we can get away with
> trap.
>> Basically, WARN_ON should also trigger a trap, so you'd end up in gdb
> for
>> that when having a breakpoint defined.
>>>>> 
>>>>> There'd need to be a way for qemu/gdb to have KVM reflect the
>>>>> exception to the guest if it doesn't have a breakpoint on file for
> that
>> address.
>>>> 
>>>> Yes, but that piece is missing for every KVM target right now. I'd
> like
>> to see something generic emerge here that we can reuse across
> different
>> architectures :).
>>> 
>>> We should try to define something that will make sense on other
>>> architectures, to whatever extent is practical -- but that doesn't
>>> mean we need to wait for them to act first. :-)
>> 
>> Oh, I agree. I'm saying we should have Jan in the discussion :).
>> 
>>>> Trap seems very tricky too though. According to page 1082 of the
> 2.06
>> spec, trap can issue a debug or a program interrupt depending on
> MSR_DE. I
>> don't see any mentioning in the spec that we intercept program or
> debug
>> interrupts. So I guess we'd have to override the offset vectors and
> handle
>> _every_ interrupt ourselves. Bleks.
>>> 
>>> Program and debug interrupts always go to the hypervisor.  Only the
>>> exceptions for which GIVORs are defined (DSI, ISI, external IRQ,
>>> syscall, TLB miss) can go directly to the guest, and even those are
>>> generally optional based on EPCR.
>> 
>> Ah, so it's a positive list. I guess I missed that part :). Thanks for
> the
>> clarification.
>> 
>> So making it a trap instruction for now should be ok. Let's align the
> code
>> to the same x86 looks like for now. In the meanwhile, let's discuss
> with
>> Jan on how to get a list of patched IPs into the kernel and implement
> that
>> on top of the code we'll have aligned with x86 by then :).
> 
> What about using the ehpriv instruction (defined in 2.06)?
> We could define a unique "qemu software breakpoint", and the
> hypervisor's ehpriv handler will be able to easily distinguish them.
> 
> On e500v2, this would be an illegal instruction.
> 
> We don't need to worry about a conflict with future opcodes
> and it seems like the whole point of ehpriv being defined-- to let
> a hypervisor define special opcodes for stuff like this.

Yes, it even states so in the little box below the description. Very good catch!

> If we use trap, we will need the list of patched IPs in 
> the kernel.   ehpriv avoids the need for that.

Well, the way it's handled on x86 now is that the kernel asks user space if it knows about the breakpoint and if not user space reinjects the debug interrupt into the guest.

Is there anything that ensures us BookS won't use 31/270?


Alex

RE: Software breakpoint in kvmppc guest debug

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, November 09, 2010 9:39 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Hollis Blanchard; Liu Yu-B13201; kvm-
> ppc@vger.kernel.org; Jan Kiszka
> Subject: Re: Software breakpoint in kvmppc guest debug
> 
> 
> On 10.11.2010, at 04:31, Yoder Stuart-B08248 wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: kvm-ppc-owner@vger.kernel.org
> > [mailto:kvm-ppc-owner@vger.kernel.org]
> >> On Behalf Of Alexander Graf
> >> Sent: Tuesday, November 09, 2010 12:50 PM
> >> To: Wood Scott-B07421
> >> Cc: Hollis Blanchard; Liu Yu-B13201; kvm-ppc@vger.kernel.org; Jan
> > Kiszka
> >> Subject: Re: Software breakpoint in kvmppc guest debug
> >>
> >>
> >> On 09.11.2010, at 19:43, Scott Wood wrote:
> >>
> >>> On Tue, 9 Nov 2010 19:26:25 +0100
> >>> Alexander Graf <agraf@suse.de> wrote:
> >>>
> >>>>
> >>>> On 09.11.2010, at 19:17, Scott Wood wrote:
> >>>>
> >>>>> On Tue, 9 Nov 2010 18:14:31 +0100
> >>>>> Alexander Graf <agraf@suse.de> wrote:
> >>>>>
> >>>>>> Now, if we can get away with not using an undefined instruction
> > (be it
> >> sc 64 or trap) I don't know. I'm not even sure we can get away with
> > trap.
> >> Basically, WARN_ON should also trigger a trap, so you'd end up in
gdb
> > for
> >> that when having a breakpoint defined.
> >>>>>
> >>>>> There'd need to be a way for qemu/gdb to have KVM reflect the
> >>>>> exception to the guest if it doesn't have a breakpoint on file
for
> > that
> >> address.
> >>>>
> >>>> Yes, but that piece is missing for every KVM target right now.
I'd
> > like
> >> to see something generic emerge here that we can reuse across
> > different
> >> architectures :).
> >>>
> >>> We should try to define something that will make sense on other
> >>> architectures, to whatever extent is practical -- but that doesn't
> >>> mean we need to wait for them to act first. :-)
> >>
> >> Oh, I agree. I'm saying we should have Jan in the discussion :).
> >>
> >>>> Trap seems very tricky too though. According to page 1082 of the
> > 2.06
> >> spec, trap can issue a debug or a program interrupt depending on
> > MSR_DE. I
> >> don't see any mentioning in the spec that we intercept program or
> > debug
> >> interrupts. So I guess we'd have to override the offset vectors and
> > handle
> >> _every_ interrupt ourselves. Bleks.
> >>>
> >>> Program and debug interrupts always go to the hypervisor.  Only
the
> >>> exceptions for which GIVORs are defined (DSI, ISI, external IRQ,
> >>> syscall, TLB miss) can go directly to the guest, and even those
are
> >>> generally optional based on EPCR.
> >>
> >> Ah, so it's a positive list. I guess I missed that part :). Thanks
> >> for
> > the
> >> clarification.
> >>
> >> So making it a trap instruction for now should be ok. Let's align
the
> > code
> >> to the same x86 looks like for now. In the meanwhile, let's discuss
> > with
> >> Jan on how to get a list of patched IPs into the kernel and
implement
> > that
> >> on top of the code we'll have aligned with x86 by then :).
> >
> > What about using the ehpriv instruction (defined in 2.06)?
> > We could define a unique "qemu software breakpoint", and the
> > hypervisor's ehpriv handler will be able to easily distinguish them.
> >
> > On e500v2, this would be an illegal instruction.
> >
> > We don't need to worry about a conflict with future opcodes and it
> > seems like the whole point of ehpriv being defined-- to let a
> > hypervisor define special opcodes for stuff like this.
> 
> Yes, it even states so in the little box below the description. Very
good
> catch!
> 
> > If we use trap, we will need the list of patched IPs in
> > the kernel.   ehpriv avoids the need for that.
> 
> Well, the way it's handled on x86 now is that the kernel asks user
space if
> it knows about the breakpoint and if not user space reinjects the
debug
> interrupt into the guest.
> 
> Is there anything that ensures us BookS won't use 31/270?

I will check with the Freescale instruction set architect.

Stuart

Re: Software breakpoint in kvmppc guest debug

[Jan Kiszka]

Am 10.11.2010 04:39, Alexander Graf wrote:
> 
> On 10.11.2010, at 04:31, Yoder Stuart-B08248 wrote:
> 
>>
>>
>>> -----Original Message-----
>>> From: kvm-ppc-owner@vger.kernel.org
>> [mailto:kvm-ppc-owner@vger.kernel.org]
>>> On Behalf Of Alexander Graf
>>> Sent: Tuesday, November 09, 2010 12:50 PM
>>> To: Wood Scott-B07421
>>> Cc: Hollis Blanchard; Liu Yu-B13201; kvm-ppc@vger.kernel.org; Jan
>> Kiszka
>>> Subject: Re: Software breakpoint in kvmppc guest debug
>>>
>>>
>>> On 09.11.2010, at 19:43, Scott Wood wrote:
>>>
>>>> On Tue, 9 Nov 2010 19:26:25 +0100
>>>> Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>>
>>>>> On 09.11.2010, at 19:17, Scott Wood wrote:
>>>>>
>>>>>> On Tue, 9 Nov 2010 18:14:31 +0100
>>>>>> Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>>> Now, if we can get away with not using an undefined instruction
>> (be it
>>> sc 64 or trap) I don't know. I'm not even sure we can get away with
>> trap.
>>> Basically, WARN_ON should also trigger a trap, so you'd end up in gdb
>> for
>>> that when having a breakpoint defined.
>>>>>>
>>>>>> There'd need to be a way for qemu/gdb to have KVM reflect the
>>>>>> exception to the guest if it doesn't have a breakpoint on file for
>> that
>>> address.
>>>>>
>>>>> Yes, but that piece is missing for every KVM target right now. I'd
>> like
>>> to see something generic emerge here that we can reuse across
>> different
>>> architectures :).
>>>>
>>>> We should try to define something that will make sense on other
>>>> architectures, to whatever extent is practical -- but that doesn't
>>>> mean we need to wait for them to act first. :-)
>>>
>>> Oh, I agree. I'm saying we should have Jan in the discussion :).
>>>
>>>>> Trap seems very tricky too though. According to page 1082 of the
>> 2.06
>>> spec, trap can issue a debug or a program interrupt depending on
>> MSR_DE. I
>>> don't see any mentioning in the spec that we intercept program or
>> debug
>>> interrupts. So I guess we'd have to override the offset vectors and
>> handle
>>> _every_ interrupt ourselves. Bleks.
>>>>
>>>> Program and debug interrupts always go to the hypervisor.  Only the
>>>> exceptions for which GIVORs are defined (DSI, ISI, external IRQ,
>>>> syscall, TLB miss) can go directly to the guest, and even those are
>>>> generally optional based on EPCR.
>>>
>>> Ah, so it's a positive list. I guess I missed that part :). Thanks for
>> the
>>> clarification.
>>>
>>> So making it a trap instruction for now should be ok. Let's align the
>> code
>>> to the same x86 looks like for now. In the meanwhile, let's discuss
>> with
>>> Jan on how to get a list of patched IPs into the kernel and implement
>> that
>>> on top of the code we'll have aligned with x86 by then :).
>>
>> What about using the ehpriv instruction (defined in 2.06)?
>> We could define a unique "qemu software breakpoint", and the
>> hypervisor's ehpriv handler will be able to easily distinguish them.
>>
>> On e500v2, this would be an illegal instruction.
>>
>> We don't need to worry about a conflict with future opcodes
>> and it seems like the whole point of ehpriv being defined-- to let
>> a hypervisor define special opcodes for stuff like this.
> 
> Yes, it even states so in the little box below the description. Very good catch!
> 
>> If we use trap, we will need the list of patched IPs in 
>> the kernel.   ehpriv avoids the need for that.
> 
> Well, the way it's handled on x86 now is that the kernel asks user space if it knows about the breakpoint and if not user space reinjects the debug interrupt into the guest.

Right. That's fine for x86 as we have a dedicated soft BP instruction.
It's shared with the guest, but as long as the latter does not start
using it heavily for whatever purpose, this "lengthy" loop to find the
trap reason is OK. It avoids dispatching tables in the kernel.

Still, if it actually turns out that PowerPC (or some other arch) needs
this for performance reasons as no proper instructions could be defined,
we should probably introduce a generic service to set a soft BP
dispatching table in the kernel. That could also be used by x86 then,
even though the practical improvement would be minimal there.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

RE: Software breakpoint in kvmppc guest debug

[Yoder Stuart-B08248]

> > > What about using the ehpriv instruction (defined in 2.06)?
> > > We could define a unique "qemu software breakpoint", and the
> > > hypervisor's ehpriv handler will be able to easily distinguish
them.
> > >
> > > On e500v2, this would be an illegal instruction.
> > >
> > > We don't need to worry about a conflict with future opcodes and it
> > > seems like the whole point of ehpriv being defined-- to let a
> > > hypervisor define special opcodes for stuff like this.
> >
> > Yes, it even states so in the little box below the description. Very
> > good catch!
> >
> > > If we use trap, we will need the list of patched IPs in
> > > the kernel.   ehpriv avoids the need for that.
> >
> > Well, the way it's handled on x86 now is that the kernel asks user
> > space if it knows about the breakpoint and if not user space
reinjects
> > the debug interrupt into the guest.
> >
> > Is there anything that ensures us BookS won't use 31/270?
> 
> I will check with the Freescale instruction set architect.

Talked to the ISA architect and he says--- ...In general the
architecture
will not overlay opcodes until all the opcode space has been exhausted,
and even then its probably not likely.

So, it seems highly unlikely that the 31/270 will ever be used for
something else.

So, it sounds like ehpriv is the way to go.

Stuart