From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031620AbbD2IK5 (ORCPT ); Wed, 29 Apr 2015 04:10:57 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:33617 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031365AbbD2IKv (ORCPT ); Wed, 29 Apr 2015 04:10:51 -0400 Date: Wed, 29 Apr 2015 10:10:47 +0200 From: Christoffer Dall To: Alex =?iso-8859-1?Q?Benn=E9e?= 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 Message-ID: <20150429081047.GB4137@cbox> References: <1427814488-28467-1-git-send-email-alex.bennee@linaro.org> <1427814488-28467-7-git-send-email-alex.bennee@linaro.org> <20150414082558.GS6186@cbox> <87y4li6hua.fsf@linaro.org> <20150427200407.GG23335@cbox> <87wq0wr6dd.fsf@linaro.org> <20150428125645.GA4137@cbox> <87tww0qqh9.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87tww0qqh9.fsf@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > >> > > >> > So you pointed out we can't just re-inject the exceptions we get as we > >> > need to map from things like ESR_ELx_EC_WATCHPT_LOW to > >> > ESR_ELx_EC_WATCHPT_CUR before re-injection. > >> > > >> > Of course if it is as simple as modifying the ESR_EL1 register and > >> > returning +ve in the handle_exit path then I can do that but I assumed > >> > if any other wrangling needs doing it should be done in userspace. > >> > >> Well, somebody's got to do it, and it's the same amount of work > >> either way (fiddling with ESR, making sure we direct the guest > >> to the right exception vector entry point, maybe a few other > >> things). > >> > > We already have code in the kernel to inject data/instruction aborts, > > but not sure how much benefit there is in re-using that. It's up to you > > really, but I think the kernel code should be clear about what the > > intention is so that we don't end up in a situation where: (1) The > > intended behavior is unclear/vague, and (2) it doesn't actually work in > > practice so nobody can follow the code. > > 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? 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. What am I missing? -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 From: christoffer.dall@linaro.org (Christoffer Dall) Date: Wed, 29 Apr 2015 10:10:47 +0200 Subject: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support In-Reply-To: <87tww0qqh9.fsf@linaro.org> References: <1427814488-28467-1-git-send-email-alex.bennee@linaro.org> <1427814488-28467-7-git-send-email-alex.bennee@linaro.org> <20150414082558.GS6186@cbox> <87y4li6hua.fsf@linaro.org> <20150427200407.GG23335@cbox> <87wq0wr6dd.fsf@linaro.org> <20150428125645.GA4137@cbox> <87tww0qqh9.fsf@linaro.org> Message-ID: <20150429081047.GB4137@cbox> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. > >> > > >> > So you pointed out we can't just re-inject the exceptions we get as we > >> > need to map from things like ESR_ELx_EC_WATCHPT_LOW to > >> > ESR_ELx_EC_WATCHPT_CUR before re-injection. > >> > > >> > Of course if it is as simple as modifying the ESR_EL1 register and > >> > returning +ve in the handle_exit path then I can do that but I assumed > >> > if any other wrangling needs doing it should be done in userspace. > >> > >> Well, somebody's got to do it, and it's the same amount of work > >> either way (fiddling with ESR, making sure we direct the guest > >> to the right exception vector entry point, maybe a few other > >> things). > >> > > We already have code in the kernel to inject data/instruction aborts, > > but not sure how much benefit there is in re-using that. It's up to you > > really, but I think the kernel code should be clear about what the > > intention is so that we don't end up in a situation where: (1) The > > intended behavior is unclear/vague, and (2) it doesn't actually work in > > practice so nobody can follow the code. > > 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? 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. What am I missing? -Christoffer