From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: Exposing host debug capabilities to userspace Date: Tue, 25 Nov 2014 17:35:11 +0100 Message-ID: <5474AFBF.6030508@suse.de> References: <87mw7l3j7x.fsf@linaro.org> <87egssn91o.fsf@zen.linaro.local.i-did-not-set--mail-host-address--so-tickle-me> <87d28cn84s.fsf@linaro.org> <87a93gn1go.fsf@linaro.org> <5474ACA1.20908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvmarm@lists.cs.columbia.edu, KVM devel mailing list To: Paolo Bonzini , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Will Deacon , Marc Zyngier , Christoffer Dall , Peter Maydell Return-path: Received: from cantor2.suse.de ([195.135.220.15]:45552 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbaKYQfO (ORCPT ); Tue, 25 Nov 2014 11:35:14 -0500 In-Reply-To: <5474ACA1.20908@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 25.11.14 17:21, Paolo Bonzini wrote: >=20 >=20 > On 24/11/2014 14:59, Alex Benn=C3=A9e wrote: >> Alexander Graf pointed out that KVM_CHECK_EXTENSION can return any >> positive number for success. How about using: >> >> max_hw_bps =3D kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_HW= _BPS); >> max_hw_wps =3D kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_HW= _WPS); >> >> Seems pretty sane, doesn't change the semantics of an API and is >> architecture agnostic if others need the number? >=20 > Yes, this was going to be my suggestion as well. Just I would use a > bitmask in case some register can act as both breakpoint and watchpoi= nt. >=20 > On x86, each of the four bp/wp registers (each register can act as bo= th) > can be used for either guest or gdbstub debugging. If the > KVM_GUESTDBG_USE_HW_BP feature is enabled, the guest is entered with > "made up" debug register contents, that we pass via > KVM_SET_GUEST_DEBUG's struct kvm_guest_debug_arch. Otherwise, the gu= est > is entered with real debug register contents passed via > KVM_SET_DEBUGREGS. Reads/writes of the debug registers trap to KVM > (which helps the guest see the expected values of the debug registers= in > the former case). There is no KVM_GET_GUEST_DEBUG because the > corresponding info is passed via struct kvm_debug_exit_arch. >=20 > If gdbstub hardware breakpoints are enabled, all hardware breakpoints > exit to userspace. QEMU then decides whether the breakpoint came fro= m > guest debugging (and then injects an exception), or from gdbstub > debugging (and then suspends execution). Same for software breakpoin= ts. > If the total request is >4 hardware breakpoints, someone will have t= o > lose and some gdbstub breakpoints will be missed. Unfortunately on ARM you also have a few other constraints - the debug register space is partitioned into magic super debug registers at the top (with an implementation specific amount) and normal debug registers in the lower end of the space. The main pain I have with exposing host information is that it's going to be interesting and challenging enough to get all of this right merel= y for the guest debug register space. Exposing the host debug register space as well means there is even more space for breakage. I would just treat gdbstub debugging as the ugly step child that it is and not introduce anything special for it (except for debug event deflection to user space). Then only ever work on guest debug registers and call it a day. Chances are just too high that we get the interfaces wrong and shoot ourselves in the foot. Alex