Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility

[David Hildenbrand <dahi@linux.vnet.ibm.com>]

> 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