> 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