Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752087AbbD2TUV (ORCPT ); Wed, 29 Apr 2015 15:20:21 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:37711 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751993AbbD2TUP convert rfc822-to-8bit (ORCPT ); Wed, 29 Apr 2015 15:20:15 -0400 MIME-Version: 1.0 In-Reply-To: <87oam70y64.fsf@linaro.org> References: <20150414082558.GS6186@cbox> <87y4li6hua.fsf@linaro.org> <20150427200407.GG23335@cbox> <87wq0wr6dd.fsf@linaro.org> <20150428125645.GA4137@cbox> <87tww0qqh9.fsf@linaro.org> <20150429081047.GB4137@cbox> <87r3r31eed.fsf@linaro.org> <20150429103814.GC4137@cbox> <87oam70y64.fsf@linaro.org> Date: Wed, 29 Apr 2015 21:20:12 +0200 Message-ID: Subject: Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support From: Christoffer Dall To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: Peter Maydell , kvm-devel , arm-mail-list , "kvmarm@lists.cs.columbia.edu" , Marc Zyngier , Alexander Graf , Andrew Jones , Paolo Bonzini , Zhichao Huang , "J. Kiszka" , David Hildenbrand , Bharat Bhushan , bp@suse.de, Gleb Natapov , Jonathan Corbet , Russell King , Catalin Marinas , Will Deacon , "open list:DOCUMENTATION" , open list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2948 Lines: 76 On Wed, Apr 29, 2015 at 5:08 PM, Alex Bennée wrote: > > Christoffer Dall writes: > >> On Wed, Apr 29, 2015 at 10:18:18AM +0100, Alex Bennée wrote: >>> >>> Christoffer Dall writes: >>> >>> > On Tue, Apr 28, 2015 at 03:37:01PM +0100, Alex Bennée wrote: >>> >> >>> >> Christoffer Dall writes: >>> >> >>> >> > On Tue, Apr 28, 2015 at 10:34:12AM +0100, Peter Maydell wrote: >>> >> >> On 28 April 2015 at 09:42, Alex Bennée wrote: >>> >> >> > Peter Maydell writes: >>> >> >> >> Does the kernel already have a conveniently implemented "inject >>> >> >> >> exception into guest" lump of code? If so it might be less effort >>> >> >> >> to do it that way round, maybe. >>> >> >> > > >>> >> >>> >> Certainly there are some cases where the kernel doesn't have all the >>> >> information. For example it doesn't know if the soft break was inserted >>> >> by the guest or the host. That to me favours the "let userspace deal >>> >> with the ugly" approach. >>> >> >>> > Not sure I follow. >>> > >>> > If it's an exception for the guest, then that must be because the guest >>> > put in the breakpoint instruction, right? >>> >>> No the host can add breakpoint instructions as well. They both generate >>> the same (redirected) exception to the hypervisor which then has to >>> figure out who planted the breakpoint and where the eventual exception >>> will be handled. >> >> I understand this; let's just rewind here. >> >> If you've concluded that the exception is for the guest, then the guest >> must have placed the breakpoint instruction there, correct? Otherwise, >> the exception is for the hypervisor and the discussion about how to >> inject an exception for the guest is invalid. > > But only userspace has enough information to make that conclusion (after > searching the list of breakpoints it added to the code). So from > userspace we can: > > - re-enter KVM telling it to re-route the exception it just delivered > to userspace somehow > > or > > - make the changes to deliver the exception in userspace and re-enter > KVM as normal. > ok, we agree and are talking about the same thing. good. > It seems to me if we have already exited into userspace it may as well > clean up if it has all the information it needs? > depends on the complexity and size of the code really, imho. >> Or are you talking about the corner case where the host uses a soft >> breakpoint to get a breakpoint on an instruction which is also a >> breakpoint in the guest? > > I think in this case host debugging just wins. > ok -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/