From owner-svn-src-all@freebsd.org Fri Dec 13 19:48:34 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 885E01D529D; Fri, 13 Dec 2019 19:48:34 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47ZLnZ37vkz4QP9; Fri, 13 Dec 2019 19:48:34 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-6.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E58CD16CC; Fri, 13 Dec 2019 19:48:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r355724 - in head: sys/amd64/include sys/amd64/vmm/amd sys/amd64/vmm/intel usr.sbin/bhyve From: John Baldwin To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201912131921.xBDJLxri060525@repo.freebsd.org> Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <60685fc4-470e-5de3-dda1-4e5689fff8a6@FreeBSD.org> Date: Fri, 13 Dec 2019 11:48:29 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <201912131921.xBDJLxri060525@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 19:48:34 -0000 On 12/13/19 11:21 AM, John Baldwin wrote: > Author: jhb > Date: Fri Dec 13 19:21:58 2019 > New Revision: 355724 > URL: https://svnweb.freebsd.org/changeset/base/355724 > > Log: > Support software breakpoints in the debug server on Intel CPUs. > > - Allow the userland hypervisor to intercept breakpoint exceptions > (BP#) in the guest. A new capability (VM_CAP_BPT_EXIT) is used to > enable this feature. These exceptions are reported to userland via > a new VM_EXITCODE_BPT that includes the length of the original > breakpoint instruction. If userland wishes to pass the exception > through to the guest, it must be explicitly re-injected via > vm_inject_exception(). > > - Export VMCS_ENTRY_INST_LENGTH as a VM_REG_GUEST_ENTRY_INST_LENGTH > pseudo-register. Injecting a BP# on Intel requires setting this to > the length of the breakpoint instruction. AMD SVM currently ignores > writes to this register (but reports success) and fails to read it. > > - Rework the per-vCPU state tracked by the debug server. Rather than > a single 'stepping_vcpu' global, add a structure for each vCPU that > tracks state about that vCPU ('stepping', 'stepped', and > 'hit_swbreak'). A global 'stopped_vcpu' tracks which vCPU is > currently reporting an event. Event handlers for MTRAP and > breakpoint exits loop until the associated event is reported to the > debugger. > > Breakpoint events are discarded if the breakpoint is not present > when a vCPU resumes in the breakpoint handler to retry submitting > the breakpoint event. > > - Maintain a linked-list of active breakpoints in response to the GDB > 'Z0' and 'z0' packets. > > Reviewed by: markj (earlier version) > MFC after: 2 months > Differential Revision: https://reviews.freebsd.org/D20309 As the manpage notes, there is a pretty large caveat with using breakpoints. The debugger wants to single-step over a breakpoint after replacing the original instruction before resuming. However, the latency between a breakpoint firing and the user responding in the debugger is such that a timer interrupt has triggered by the time the vCPU resumes. Thus, the single step stops in the first instruction of the interrupt handler. The debugger then does the user's requested continue which finishes the interrupt handler and trips the breakpoint again at the original location when the interrupt handler returns. The effect is that doing a continue after a breakpoint never makes forward progress. One workaround is to disable the current breakpoint and use 'until' to set a temporary breakpoint at the next line in the source. You can then re-enable the original breakpoint and continue. I've thought about various ways to fix this, but they all have downsides. One way is to clear IF in %eflags while stepping, but then you have to emulate pushf and possibly popf. Another option might be to add new commands to pause and unpause timer devices and pause timers when the vCPUs all exit and re-enable when either doing a continue or for the duration of a step. The latter approach feels a bit more of what you want, but it has other potential downsides, like time jumps in the guest, etc. -- John Baldwin