From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Exposing host debug capabilities to userspace Date: Tue, 25 Nov 2014 17:44:37 +0100 Message-ID: <5474B1F5.6050801@redhat.com> References: <87d28cn84s.fsf@linaro.org> <547323EB.6070203@suse.de> <90CBB8A1-39B6-4113-BD0E-473A961D7F58@suse.de> <547329BA.4090107@suse.de> <54732B11.5000208@suse.de> <54733BA7.9000400@suse.de> <20141124145208.GQ3401@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Peter Maydell , =?windows-1252?Q?Alex_Ben?= =?windows-1252?Q?n=E9e?= , Will Deacon , Marc Zyngier , "kvmarm@lists.cs.columbia.edu" , KVM devel mailing list To: Christoffer Dall , Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51015 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752071AbaKYQoz (ORCPT ); Tue, 25 Nov 2014 11:44:55 -0500 In-Reply-To: <20141124145208.GQ3401@cbox> Sender: kvm-owner@vger.kernel.org List-ID: On 24/11/2014 15:52, Christoffer Dall wrote: >=20 > We had a lenghty IRC discussion on this, for the curious, go read it > here: > http://irclogs.linaro.org/2014/11/24/%23kvm-arm.html Some notes... > chazy but saying that you want to design an ABI that potentially expo= ses fewer debug registers to gdbstubs than your hardware supports and b= reaks gdbstub support if you happen to support emulation of a cpu with = more debug registers in the future, because you want to re-use ONE_REG = is not a great approach either >=20 > agraf chazy: but you wouldn't even remotely think of doing it, no? >=20 > agraf chazy: I'm saying that QEMU shouldn't have access to the excess= registers >=20 > chazy agraf: I wouldn=92t even remotely think of doing nested virtual= ization, but people have >=20 > agraf chazy: QEMU spawns an A57, it gets 8 debug registers >=20 > chazy agraf: I understand, but I don=92t agree with your rationale >=20 > agraf chazy: not "QEMU spawns an A57 on an A67, so it gets 8 real and= 8 hidden debug registers that it also needs to be aware of mappings of= " I disagree with Alex. QEMU can use the 16 debug registers as it wishes= , since it sets them with KVM_SET_GUEST_DEBUG. The guest's eight can be mapped to the last 8 if those are the required semantics for the architecture. Just exit to QEMU if you do a debug register write while gdbstub debugging is active; QEMU gets the contents of the 8 VCPU-visible registers with ONE_REG (equivalent of x86 GET_DEBUGREGS); calls KVM_SET_GUEST_DEBUG to reflect them in the 16-register state; and restarts. It works as long as you can trap both reads and writes. > chazy ajb-linaro: don=92t migrate a guest that is getting debugged is > the answer to that one I believe >=20 > ajb-linaro chazy: at least with the overlay approach that happens aut= omatically >=20 > ajb-linaro the overlay isn't migrated and the new host isn't calling = SET_GUEST_DEBUG so whatever the debug registers where before are restor= erd Right. The destination will lose the hardware breakpoints/watchpoints because it starts the guest with KVM_SET_GUEST_DEBUG. Apart from losin= g them, everything should work fine. The dest sets the 8 VCPU-visible registers with ONE_REG, the hypervisor reflects them in a subset of the 16 physical registers, and "that's it". Paolo