[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest P
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility |
Date: |
Wed, 4 Jun 2014 10:31:35 +0200 |
> On 30/05/14 11:01, Alexander Graf wrote:
> >
> > On 30.05.14 10:57, Christian Borntraeger wrote:
> >> On 30/05/14 10:32, Alexander Graf wrote:
> >>
> >>>> + case KVM_HW_BP:
> >>>> + if (find_hw_breakpoint(arch_info->addr, -1, arch_info->type)) {
> >>>> + ret = EXCP_DEBUG;
> >>>> + }
> >>>> + break;
> >>>> + case KVM_SINGLESTEP:
> >>>> + if (cs->singlestep_enabled) {
> >>>> + ret = EXCP_DEBUG;
> >>>> + }
> >>>> + break;
> >>>> + default:
> >>>> + ret = -ENOSYS;
> >>>> + }
> >>>> +
> >>>> + return ret;
> >>> What happens to the diag 501 now? Are we safe to just drop it?
> >> There can only be a small number of HW breakpoints (basically only one
> >> from-to range on s390).
> >> So gdb can (and will) use both (hbreak vs. break)
> >
> > Ah, let me explain what I'm referring to here. On x86 (and PPC, though the
> > patches are still missing), we use a generic "breakpoint" instruction for
> > sw breakpoints. The specific breakpoint interrupt generated by that
> > instruction traps into KVM which forwards it to QEMU.
> >
> > If QEMU now detects that it didn't put the breakpoint into place, it
> > assumes that it's the guest that wanted the breakpoint to happen, so it
> > deflects a breakpoint interrupt into the guest.
> >
> > My question here is whether we need something similar on s390x. With DIAG,
> > I think we're safe, as the guest can't expect that one to do anything
> > useful, but if we want to switch to a 2-byte breakpoint instruction
> > instead, it might make sense to implement the deflection mechanism.
>
> Oh, I though "What happens to the diag 501 now? Are we safe to just drop it?"
> was a question if we can get rid of the code.
> Regarding deflection, yes if guest and host hardware breakpoints (PER) we
> need to handle that (The host kernel is doing that in filter_guest_per_event)
> With software breakpoints: yes diag501 is safe to use. When we change the
> instruction later on then we have to see if we need deflection (could be).
>
> Christian
Hi Alex,
I am already working on a solution for 2 byte software breakpoints.
The solution will most likely look like what we have on x86: A generic
breakpoint instruction (e.g. invalid opcode 0x0001) that is filtered in
QEMU. We'll need kernel support to allow invalid instructions to be
intercepted and handled in QEMU. I already have a prototype running.
David
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility,
David Hildenbrand <=