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 16:08:51 +0100 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D44B64EF2B for ; Wed, 29 Apr 2015 11:00:06 -0400 (EDT) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO8n-tr6Cu1t for ; Wed, 29 Apr 2015 11:00:05 -0400 (EDT) Received: from socrates.bennee.com (static.88-198-71-155.clients.your-server.de [88.198.71.155]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 612A34EF29 for ; Wed, 29 Apr 2015 11:00:05 -0400 (EDT) In-reply-to: <20150429103814.GC4137@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 To: Christoffer Dall 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 List-Id: kvmarm@lists.cs.columbia.edu CkNocmlzdG9mZmVyIERhbGwgPGNocmlzdG9mZmVyLmRhbGxAbGluYXJvLm9yZz4gd3JpdGVzOgoK PiBPbiBXZWQsIEFwciAyOSwgMjAxNSBhdCAxMDoxODoxOEFNICswMTAwLCBBbGV4IEJlbm7DqWUg d3JvdGU6Cj4+IAo+PiBDaHJpc3RvZmZlciBEYWxsIDxjaHJpc3RvZmZlci5kYWxsQGxpbmFyby5v cmc+IHdyaXRlczoKPj4gCj4+ID4gT24gVHVlLCBBcHIgMjgsIDIwMTUgYXQgMDM6Mzc6MDFQTSAr MDEwMCwgQWxleCBCZW5uw6llIHdyb3RlOgo+PiA+PiAKPj4gPj4gQ2hyaXN0b2ZmZXIgRGFsbCA8 Y2hyaXN0b2ZmZXIuZGFsbEBsaW5hcm8ub3JnPiB3cml0ZXM6Cj4+ID4+IAo+PiA+PiA+IE9uIFR1 ZSwgQXByIDI4LCAyMDE1IGF0IDEwOjM0OjEyQU0gKzAxMDAsIFBldGVyIE1heWRlbGwgd3JvdGU6 Cj4+ID4+ID4+IE9uIDI4IEFwcmlsIDIwMTUgYXQgMDk6NDIsIEFsZXggQmVubsOpZSA8YWxleC5i ZW5uZWVAbGluYXJvLm9yZz4gd3JvdGU6Cj4+ID4+ID4+ID4gUGV0ZXIgTWF5ZGVsbCA8cGV0ZXIu bWF5ZGVsbEBsaW5hcm8ub3JnPiB3cml0ZXM6Cj4+ID4+ID4+ID4+IERvZXMgdGhlIGtlcm5lbCBh bHJlYWR5IGhhdmUgYSBjb252ZW5pZW50bHkgaW1wbGVtZW50ZWQgImluamVjdAo+PiA+PiA+PiA+ PiBleGNlcHRpb24gaW50byBndWVzdCIgbHVtcCBvZiBjb2RlPyBJZiBzbyBpdCBtaWdodCBiZSBs ZXNzIGVmZm9ydAo+PiA+PiA+PiA+PiB0byBkbyBpdCB0aGF0IHdheSByb3VuZCwgbWF5YmUuCj4+ ID4+ID4+ID4KPHNuaXA+Cj4+ID4+IAo+PiA+PiBDZXJ0YWlubHkgdGhlcmUgYXJlIHNvbWUgY2Fz ZXMgd2hlcmUgdGhlIGtlcm5lbCBkb2Vzbid0IGhhdmUgYWxsIHRoZQo+PiA+PiBpbmZvcm1hdGlv bi4gRm9yIGV4YW1wbGUgaXQgZG9lc24ndCBrbm93IGlmIHRoZSBzb2Z0IGJyZWFrIHdhcyBpbnNl cnRlZAo+PiA+PiBieSB0aGUgZ3Vlc3Qgb3IgdGhlIGhvc3QuIFRoYXQgdG8gbWUgZmF2b3VycyB0 aGUgImxldCB1c2Vyc3BhY2UgZGVhbAo+PiA+PiB3aXRoIHRoZSB1Z2x5IiBhcHByb2FjaC4KPj4g Pj4gCj4+ID4gTm90IHN1cmUgSSBmb2xsb3cuCj4+ID4KPj4gPiBJZiBpdCdzIGFuIGV4Y2VwdGlv biBmb3IgdGhlIGd1ZXN0LCB0aGVuIHRoYXQgbXVzdCBiZSBiZWNhdXNlIHRoZSBndWVzdAo+PiA+ IHB1dCBpbiB0aGUgYnJlYWtwb2ludCBpbnN0cnVjdGlvbiwgcmlnaHQ/Cj4+IAo+PiBObyB0aGUg aG9zdCBjYW4gYWRkIGJyZWFrcG9pbnQgaW5zdHJ1Y3Rpb25zIGFzIHdlbGwuIFRoZXkgYm90aCBn ZW5lcmF0ZQo+PiB0aGUgc2FtZSAocmVkaXJlY3RlZCkgZXhjZXB0aW9uIHRvIHRoZSBoeXBlcnZp c29yIHdoaWNoIHRoZW4gaGFzIHRvCj4+IGZpZ3VyZSBvdXQgd2hvIHBsYW50ZWQgdGhlIGJyZWFr cG9pbnQgYW5kIHdoZXJlIHRoZSBldmVudHVhbCBleGNlcHRpb24KPj4gd2lsbCBiZSBoYW5kbGVk Lgo+Cj4gSSB1bmRlcnN0YW5kIHRoaXM7IGxldCdzIGp1c3QgcmV3aW5kIGhlcmUuCj4KPiBJZiB5 b3UndmUgY29uY2x1ZGVkIHRoYXQgdGhlIGV4Y2VwdGlvbiBpcyBmb3IgdGhlIGd1ZXN0LCB0aGVu IHRoZSBndWVzdAo+IG11c3QgaGF2ZSBwbGFjZWQgdGhlIGJyZWFrcG9pbnQgaW5zdHJ1Y3Rpb24g dGhlcmUsIGNvcnJlY3Q/ICBPdGhlcndpc2UsCj4gdGhlIGV4Y2VwdGlvbiBpcyBmb3IgdGhlIGh5 cGVydmlzb3IgYW5kIHRoZSBkaXNjdXNzaW9uIGFib3V0IGhvdyB0bwo+IGluamVjdCBhbiBleGNl cHRpb24gZm9yIHRoZSBndWVzdCBpcyBpbnZhbGlkLgoKQnV0IG9ubHkgdXNlcnNwYWNlIGhhcyBl bm91Z2ggaW5mb3JtYXRpb24gdG8gbWFrZSB0aGF0IGNvbmNsdXNpb24gKGFmdGVyCnNlYXJjaGlu ZyB0aGUgbGlzdCBvZiBicmVha3BvaW50cyBpdCBhZGRlZCB0byB0aGUgY29kZSkuIFNvIGZyb20K dXNlcnNwYWNlIHdlIGNhbjoKCiAgLSByZS1lbnRlciBLVk0gdGVsbGluZyBpdCB0byByZS1yb3V0 ZSB0aGUgZXhjZXB0aW9uIGl0IGp1c3QgZGVsaXZlcmVkCiAgICB0byB1c2Vyc3BhY2Ugc29tZWhv dwoKICBvcgoKICAtIG1ha2UgdGhlIGNoYW5nZXMgdG8gZGVsaXZlciB0aGUgZXhjZXB0aW9uIGlu IHVzZXJzcGFjZSBhbmQgcmUtZW50ZXIKICAgIEtWTSBhcyBub3JtYWwuCgpJdCBzZWVtcyB0byBt ZSBpZiB3ZSBoYXZlIGFscmVhZHkgZXhpdGVkIGludG8gdXNlcnNwYWNlIGl0IG1heSBhcyB3ZWxs CmNsZWFuIHVwIGlmIGl0IGhhcyBhbGwgdGhlIGluZm9ybWF0aW9uIGl0IG5lZWRzPwoKPiBPciBh cmUgeW91IHRhbGtpbmcgYWJvdXQgdGhlIGNvcm5lciBjYXNlIHdoZXJlIHRoZSBob3N0IHVzZXMg YSBzb2Z0Cj4gYnJlYWtwb2ludCB0byBnZXQgYSBicmVha3BvaW50IG9uIGFuIGluc3RydWN0aW9u IHdoaWNoIGlzIGFsc28gYQo+IGJyZWFrcG9pbnQgaW4gdGhlIGd1ZXN0PwoKSSB0aGluayBpbiB0 aGlzIGNhc2UgaG9zdCBkZWJ1Z2dpbmcganVzdCB3aW5zLgoKPgo+PiAKPj4gPiBIb3dldmVyLCB0 aGF0J3MgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uIGZyb20gdGhhdCBvZiAqaG93KiB1c2Vyc3BhY2Ug b3IKPj4gPiB0aGUga2VybmVsIHRoZW4gaW5qZWN0cyBhbiBleGNlcHRpb24gdG8gdGhlIGd1ZXN0 Lgo+PiA+Cj4+ID4gQnkgdXNpbmcgc29tZSBRRU1VIFRDRyBmdW5jdGlvbmFsaXR5IG9yIGJ5IFFF TVUgY2FsbGluZyBiYWNrIGludG8gS1ZNCj4+ID4gYW5kIGFza2luZyBpdCB0byBpbmplY3QgYW4g ZXhjZXB0aW9uIGZvciBpdC4KPj4gCj4+IEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBpcyBleHBsaWNp dCBUQ0cgZnVuY3Rpb25hbGl0eSB0byB1c2UgYnV0IFFFTVUgY2FuCj4+IHNldCB0aGUgcmVnaXN0 ZXJzIGFuZCBQQyB1cCBmb3IgZXhjZXB0aW9uIGVudHJ5IGFuZCByZS1lbnRlciBLVk0uCj4+IAo+ Cj4gSSBhbHNvIHVuZGVyc3RhbmQgdGhpcy4gIEkgdGhpbmsgUGV0ZXIncyBwb2ludCB3YXMgZXhh Y3RseSB0aGF0IGlmIHdlCj4gaGF2ZSBleGlzdGluZyBjb2RlIHNvbWV3aGVyZSB3aGljaCB3ZSBj YW4gcmV1c2UsIHRoZW4gd2Ugc2hvdWxkIGNvbnNpZGVyCj4gcmV1c2luZyBpdC4KCkknbSBub3Qg c3VyZSBzdWNoIGNvZGUgZXhpc3RzLiBUaGUgb25seSBpbmplY3Rpb24gY29kZSBJIGtub3cgb2Yg aW4gS1ZNcwpoYW5kbGVfZXhpdCBjb2RlIHdoZXJlIGEgK3ZlIHJldHVybiB2YWx1ZSBzaWduYWxz IEtWTSB0byBkZWxpdmVyIHRoZQpleGNlcHRpb24gdG8gdGhlIGd1ZXN0LiBUaGlzIGlzIHVzZWQg YnkgdGhlIGh2YyBhbmQgc3ZjIGhhbmRsZXJzIGFmdGVyCmNhbGxpbmcga3ZtX2luamVjdF91bmRl ZmluZWQoKSBhbmQgdGhlIHdmeCBoYW5kbGVyIHdoaWNoIGFkdmFuY2VzIHRoZSBQQwpmaXJzdC4K Cj4gQWdhaW4sIEkgZG9uJ3QgY2FyZSBwYXJ0aWN1bGFybHkgd2hpY2ggd2F5LCBJIGp1c3Qgd2Fu dCB0aGUgZXhwZWN0ZWQKPiB3b3JraW5nIGJlaGF2aW9yIHRvIGJlIGNsZWFybHkgZGVmaW5lZC4K CkkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gZG8gaXQgaW4gdXNlcnNwYWNlLiBJIGhhdmUgdGhl IGtlcm5lbHMKaW5qZWN0X2ZhdWx0IGNvZGUgZm9yIHJlZmVyZW5jZSBmb3Igd2hhdCBuZWVkcyBz ZXR0aW5nIHVwIGJ1dCBJJ2xsIHNlZQppZiBJIGNhbiBmaW5kIGFueXRoaW5nIGluIFFFTVUgdGhh dCBhbHJlYWR5IGhhbmRsZXMgdGhpcyBmb3Igc29tZSBvdGhlcgp0aGluZyAoYWx0aG91Z2ggSSBk b24ndCB0aGluayBpdCBkb2VzIGF0IGZpcnN0IGdsYW5jZSkuCgotLSAKQWxleCBCZW5uw6llCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmt2bWFybSBtYWls aW5nIGxpc3QKa3ZtYXJtQGxpc3RzLmNzLmNvbHVtYmlhLmVkdQpodHRwczovL2xpc3RzLmNzLmNv bHVtYmlhLmVkdS9tYWlsbWFuL2xpc3RpbmZvL2t2bWFybQo= 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 16:08:51 +0100 Subject: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support In-Reply-To: <20150429103814.GC4137@cbox> 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> Message-ID: <87oam70y64.fsf@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 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 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