From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422813AbbD2JSW (ORCPT ); Wed, 29 Apr 2015 05:18:22 -0400 Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:57441 "EHLO socrates.bennee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031672AbbD2JSC (ORCPT ); Wed, 29 Apr 2015 05:18:02 -0400 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> <20150429081047.GB4137@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: <20150429081047.GB4137@cbox> Date: Wed, 29 Apr 2015 10:18:18 +0100 Message-ID: <87r3r31eed.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 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. >> >> > >> >> > 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? 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. > 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. > > What am I missing? > > -Christoffer -- Alex Bennée From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex =?utf-8?Q?Benn=C3=A9e?= Subject: Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support Date: Wed, 29 Apr 2015 10:18:18 +0100 Message-ID: <87r3r31eed.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> <20150429081047.GB4137@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Russell King , kvm-devel , Jonathan Corbet , Marc Zyngier , "J. Kiszka" , "open list:DOCUMENTATION" , Will Deacon , open list , David Hildenbrand , Catalin Marinas , Zhichao Huang , Bharat Bhushan , Paolo Bonzini , bp@suse.de, Gleb Natapov , "kvmarm@lists.cs.columbia.edu" , arm-mail-list To: Christoffer Dall Return-path: In-reply-to: <20150429081047.GB4137@cbox> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org CkNocmlzdG9mZmVyIERhbGwgPGNocmlzdG9mZmVyLmRhbGxAbGluYXJvLm9yZz4gd3JpdGVzOgoK PiBPbiBUdWUsIEFwciAyOCwgMjAxNSBhdCAwMzozNzowMVBNICswMTAwLCBBbGV4IEJlbm7DqWUg d3JvdGU6Cj4+IAo+PiBDaHJpc3RvZmZlciBEYWxsIDxjaHJpc3RvZmZlci5kYWxsQGxpbmFyby5v cmc+IHdyaXRlczoKPj4gCj4+ID4gT24gVHVlLCBBcHIgMjgsIDIwMTUgYXQgMTA6MzQ6MTJBTSAr MDEwMCwgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4gPj4gT24gMjggQXByaWwgMjAxNSBhdCAwOTo0 MiwgQWxleCBCZW5uw6llIDxhbGV4LmJlbm5lZUBsaW5hcm8ub3JnPiB3cm90ZToKPj4gPj4gPiBQ ZXRlciBNYXlkZWxsIDxwZXRlci5tYXlkZWxsQGxpbmFyby5vcmc+IHdyaXRlczoKPj4gPj4gPj4g RG9lcyB0aGUga2VybmVsIGFscmVhZHkgaGF2ZSBhIGNvbnZlbmllbnRseSBpbXBsZW1lbnRlZCAi aW5qZWN0Cj4+ID4+ID4+IGV4Y2VwdGlvbiBpbnRvIGd1ZXN0IiBsdW1wIG9mIGNvZGU/IElmIHNv IGl0IG1pZ2h0IGJlIGxlc3MgZWZmb3J0Cj4+ID4+ID4+IHRvIGRvIGl0IHRoYXQgd2F5IHJvdW5k LCBtYXliZS4KPj4gPj4gPgo+PiA+PiA+IFNvIHlvdSBwb2ludGVkIG91dCB3ZSBjYW4ndCBqdXN0 IHJlLWluamVjdCB0aGUgZXhjZXB0aW9ucyB3ZSBnZXQgYXMgd2UKPj4gPj4gPiBuZWVkIHRvIG1h cCBmcm9tIHRoaW5ncyBsaWtlIEVTUl9FTHhfRUNfV0FUQ0hQVF9MT1cgdG8KPj4gPj4gPiBFU1Jf RUx4X0VDX1dBVENIUFRfQ1VSIGJlZm9yZSByZS1pbmplY3Rpb24uCj4+ID4+ID4KPj4gPj4gPiBP ZiBjb3Vyc2UgaWYgaXQgaXMgYXMgc2ltcGxlIGFzIG1vZGlmeWluZyB0aGUgRVNSX0VMMSByZWdp c3RlciBhbmQKPj4gPj4gPiByZXR1cm5pbmcgK3ZlIGluIHRoZSBoYW5kbGVfZXhpdCBwYXRoIHRo ZW4gSSBjYW4gZG8gdGhhdCBidXQgSSBhc3N1bWVkCj4+ID4+ID4gaWYgYW55IG90aGVyIHdyYW5n bGluZyBuZWVkcyBkb2luZyBpdCBzaG91bGQgYmUgZG9uZSBpbiB1c2Vyc3BhY2UuCj4+ID4+IAo+ PiA+PiBXZWxsLCBzb21lYm9keSdzIGdvdCB0byBkbyBpdCwgYW5kIGl0J3MgdGhlIHNhbWUgYW1v dW50IG9mIHdvcmsKPj4gPj4gZWl0aGVyIHdheSAoZmlkZGxpbmcgd2l0aCBFU1IsIG1ha2luZyBz dXJlIHdlIGRpcmVjdCB0aGUgZ3Vlc3QKPj4gPj4gdG8gdGhlIHJpZ2h0IGV4Y2VwdGlvbiB2ZWN0 b3IgZW50cnkgcG9pbnQsIG1heWJlIGEgZmV3IG90aGVyCj4+ID4+IHRoaW5ncykuCj4+ID4+IAo+ PiA+IFdlIGFscmVhZHkgaGF2ZSBjb2RlIGluIHRoZSBrZXJuZWwgdG8gaW5qZWN0IGRhdGEvaW5z dHJ1Y3Rpb24gYWJvcnRzLAo+PiA+IGJ1dCBub3Qgc3VyZSBob3cgbXVjaCBiZW5lZml0IHRoZXJl IGlzIGluIHJlLXVzaW5nIHRoYXQuICBJdCdzIHVwIHRvIHlvdQo+PiA+IHJlYWxseSwgYnV0IEkg dGhpbmsgdGhlIGtlcm5lbCBjb2RlIHNob3VsZCBiZSBjbGVhciBhYm91dCB3aGF0IHRoZQo+PiA+ IGludGVudGlvbiBpcyBzbyB0aGF0IHdlIGRvbid0IGVuZCB1cCBpbiBhIHNpdHVhdGlvbiB3aGVy ZTogKDEpIFRoZQo+PiA+IGludGVuZGVkIGJlaGF2aW9yIGlzIHVuY2xlYXIvdmFndWUsIGFuZCAo MikgaXQgZG9lc24ndCBhY3R1YWxseSB3b3JrIGluCj4+ID4gcHJhY3RpY2Ugc28gbm9ib2R5IGNh biBmb2xsb3cgdGhlIGNvZGUuCj4+IAo+PiBDZXJ0YWlubHkgdGhlcmUgYXJlIHNvbWUgY2FzZXMg d2hlcmUgdGhlIGtlcm5lbCBkb2Vzbid0IGhhdmUgYWxsIHRoZQo+PiBpbmZvcm1hdGlvbi4gRm9y IGV4YW1wbGUgaXQgZG9lc24ndCBrbm93IGlmIHRoZSBzb2Z0IGJyZWFrIHdhcyBpbnNlcnRlZAo+ PiBieSB0aGUgZ3Vlc3Qgb3IgdGhlIGhvc3QuIFRoYXQgdG8gbWUgZmF2b3VycyB0aGUgImxldCB1 c2Vyc3BhY2UgZGVhbAo+PiB3aXRoIHRoZSB1Z2x5IiBhcHByb2FjaC4KPj4gCj4gTm90IHN1cmUg SSBmb2xsb3cuCj4KPiBJZiBpdCdzIGFuIGV4Y2VwdGlvbiBmb3IgdGhlIGd1ZXN0LCB0aGVuIHRo YXQgbXVzdCBiZSBiZWNhdXNlIHRoZSBndWVzdAo+IHB1dCBpbiB0aGUgYnJlYWtwb2ludCBpbnN0 cnVjdGlvbiwgcmlnaHQ/CgpObyB0aGUgaG9zdCBjYW4gYWRkIGJyZWFrcG9pbnQgaW5zdHJ1Y3Rp b25zIGFzIHdlbGwuIFRoZXkgYm90aCBnZW5lcmF0ZQp0aGUgc2FtZSAocmVkaXJlY3RlZCkgZXhj ZXB0aW9uIHRvIHRoZSBoeXBlcnZpc29yIHdoaWNoIHRoZW4gaGFzIHRvCmZpZ3VyZSBvdXQgd2hv IHBsYW50ZWQgdGhlIGJyZWFrcG9pbnQgYW5kIHdoZXJlIHRoZSBldmVudHVhbCBleGNlcHRpb24K d2lsbCBiZSBoYW5kbGVkLgoKPiBIb3dldmVyLCB0aGF0J3MgYSBzZXBhcmF0ZSBkaXNjdXNzaW9u IGZyb20gdGhhdCBvZiAqaG93KiB1c2Vyc3BhY2Ugb3IKPiB0aGUga2VybmVsIHRoZW4gaW5qZWN0 cyBhbiBleGNlcHRpb24gdG8gdGhlIGd1ZXN0Lgo+Cj4gQnkgdXNpbmcgc29tZSBRRU1VIFRDRyBm dW5jdGlvbmFsaXR5IG9yIGJ5IFFFTVUgY2FsbGluZyBiYWNrIGludG8gS1ZNCj4gYW5kIGFza2lu ZyBpdCB0byBpbmplY3QgYW4gZXhjZXB0aW9uIGZvciBpdC4KCkkgZG9uJ3Qga25vdyBpZiB0aGVy ZSBpcyBleHBsaWNpdCBUQ0cgZnVuY3Rpb25hbGl0eSB0byB1c2UgYnV0IFFFTVUgY2FuCnNldCB0 aGUgcmVnaXN0ZXJzIGFuZCBQQyB1cCBmb3IgZXhjZXB0aW9uIGVudHJ5IGFuZCByZS1lbnRlciBL Vk0uCgo+Cj4gV2hhdCBhbSBJIG1pc3Npbmc/Cj4KPiAtQ2hyaXN0b2ZmZXIKCi0tIApBbGV4IEJl bm7DqWUKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Ka3Zt YXJtIG1haWxpbmcgbGlzdAprdm1hcm1AbGlzdHMuY3MuY29sdW1iaWEuZWR1Cmh0dHBzOi8vbGlz dHMuY3MuY29sdW1iaWEuZWR1L21haWxtYW4vbGlzdGluZm8va3ZtYXJtCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex.bennee@linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=) Date: Wed, 29 Apr 2015 10:18:18 +0100 Subject: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support In-Reply-To: <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> <20150429081047.GB4137@cbox> Message-ID: <87r3r31eed.fsf@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. >> >> > >> >> > 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? 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. > 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. > > What am I missing? > > -Christoffer -- Alex Benn?e