From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws6gW-0007aD-Jt for qemu-devel@nongnu.org; Wed, 04 Jun 2014 04:36:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ws6gN-0002zl-2b for qemu-devel@nongnu.org; Wed, 04 Jun 2014 04:36:36 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:48675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws6gM-0002y6-QS for qemu-devel@nongnu.org; Wed, 04 Jun 2014 04:36:27 -0400 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jun 2014 09:36:25 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 472B017D804E for ; Wed, 4 Jun 2014 09:37:40 +0100 (BST) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps3075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s548aMMX23724048 for ; Wed, 4 Jun 2014 08:36:22 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s548aHrn024074 for ; Wed, 4 Jun 2014 02:36:21 -0600 Date: Wed, 4 Jun 2014 10:31:35 +0200 From: David Hildenbrand Message-ID: <20140604103135.080d2269@thinkpad-w530> In-Reply-To: <53884B77.8020206@de.ibm.com> References: <1399896944-49359-1-git-send-email-jfrei@linux.vnet.ibm.com> <1399896944-49359-5-git-send-email-jfrei@linux.vnet.ibm.com> <53884206.8090502@suse.de> <538847E4.5020101@de.ibm.com> <538848D9.7010907@suse.de> <53884B77.8020206@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: Cornelia Huck , Jens Freimann , Alexander Graf , qemu-devel@nongnu.org > 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