Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423446AbbD2PIk (ORCPT ); Wed, 29 Apr 2015 11:08:40 -0400 Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:58822 "EHLO socrates.bennee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423016AbbD2PIh (ORCPT ); Wed, 29 Apr 2015 11:08:37 -0400 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> From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Christoffer Dall 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 Subject: Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support In-reply-to: <20150429103814.GC4137@cbox> Date: Wed, 29 Apr 2015 16:08:51 +0100 Message-ID: <87oam70y64.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: alex.bennee@linaro.org X-SA-Exim-Scanned: No (on socrates.bennee.com); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3948 Lines: 100 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. 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? > 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. > >> >> > However, that's a separate discussion from that of *how* userspace or >> > the kernel then injects an exception to the guest. >> > >> > By using some QEMU TCG functionality or by QEMU calling back into KVM >> > and asking it to inject an exception for it. >> >> I don't know if there is explicit TCG functionality to use but QEMU can >> set the registers and PC up for exception entry and re-enter KVM. >> > > I also understand this. I think Peter's point was exactly that if we > have existing code somewhere which we can reuse, then we should consider > reusing it. I'm not sure such code exists. The only injection code I know of in KVMs handle_exit code where a +ve return value signals KVM to deliver the exception to the guest. This is used by the hvc and svc handlers after calling kvm_inject_undefined() and the wfx handler which advances the PC first. > Again, I don't care particularly which way, I just want the expected > working behavior to be clearly defined. I think it makes sense to do it in userspace. I have the kernels inject_fault code for reference for what needs setting up but I'll see if I can find anything in QEMU that already handles this for some other thing (although I don't think it does at first glance). -- Alex Bennée -- 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/