[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 1/6] x86/debugger: Remove debugger_trap_entry()
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Thu, 21 Apr 2022 17:23:16 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Tl1ED7Ej7WCZr84wo1pq0ZwpBz7um8FadlQl+zoIHYo=; b=iCDkWV8JDOchhPPxNgCFXqqMeHdj03z7HsU5t5xoWD6Obeoe28WR2OQECZf216ae0B/optqbJpPG/uDAGxgoJ0LlfA79ZHD4fuDDOTm9L/tdlYZJlHnO5CzhzLqlLRCocj+y+E6ca5eaDRNKipuKYvZvGf3mahrWDkHyqytHWTbpPdvJEK1KGhLj7cNCDMyPHMH4g6NV71B+AtrnldPADt8eCtofAGGZ8DnOdIgi0YfTDuGQXbMbS6WbUZHg7DiWARHDVDO45RQ11jzhUUH1kd9mSOHQQl+/FQcve9yPOGZDi01DvU3OLBlu1qIbOGLLhlZXl0RX+451SVKJVg4dcg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O87t7QhzHJ0BFLX6i+Q53OubkXjRIpZjz6nSgSHzkTOm823kpySEpyOxsy7mIEyq6+aqkZiabxhQ5ap4I7kTzTAaeTQfCX6R783DfNILUMXeiBuydEEAguzKZ6Qckqv1zlSCfwoZHsS5F6poeVaTZohadxJzi6DGG29tZnz0VShPOWWpvgUOCbJV5Mny0mFfU/Jrh0wqs8eHqB5vNksW7WgHB0/KEp8chcmzH7cGrxwyr+zBQvQQDD/WsLy+DX/J+6xlH12USZQSUvJhPH++bvZin1qaXxfOvRHCU6z6ugsWfeaFuWaII5jt1PE/m5MYvEtc3QPAFn0AuIYEBcbfXQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Bobby Eshleman <bobby.eshleman@xxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 21 Apr 2022 17:23:37 +0000
- Ironport-data: A9a23:ImBUr66ZYjbJgTsivxn6igxRtDLGchMFZxGqfqrLsTDasY5as4F+v mMdUG+Fbv3cN2egKtF3bIqz9B4D65/VmNRkHQtrqylhHi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG96yE6j8lkf5KkYAL+EnkZqTRMFWFw0XqPp8Zj2tQy2YTjWlvX0 T/Pi5a31GGNimYc3l08s8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vNvy7X 47+IISRpQs1yfuP5uSNyd4XemVSKlLb0JPnZnB+A8BOiTAazsA+PzpS2FPxpi67hh3Q9+2dx umhurSvWxgZDqP3xt0QVgRXPAV0AOpl/7LudC3XXcy7lyUqclPK6tA2VgQcG9Rd/ex6R2ZT6 fYfNTYBKAiZgP67y666Te8qgdk/KM7sP8UUvXQIITPxVK56B8ycBfiTo4MHtNszrpkm8fL2T swVczdwKj/HZAVCIAw/A5Mihua4wHL4dlW0rXrK//JouTeMk2Sd1pDxKtX4R8GIHv4OtUyit 2nMz030WCgVYYn3JT2ttyjEavX0tSHxVZ8WFba43uV3m1DVzWsWYDUcUlGxsL+0kU66VtdWL WQb/yMvqe4580nDZsb5dw21pjiDpBF0c8pdFag25R+AzoLQ4h2FHS4UQzhZctskucQqAzsw2 Te0c8jBADVutPifTyub/7LM8jeqY3BJcikFeDMOShYD75/7uoYvgxnTT9FlVqmoktnyHjK2y DePxMQju4guYQcw//3T1Tj6b/iE/PAlkiZdCt3rY1+Y
- Ironport-hdrordr: A9a23:1M69iaOvf0W1RcBcT5j255DYdb4zR+YMi2TDiHoddfUFSKalfp 6V98jzjSWE8wr4WBkb6LO90DHpewKRyXcH2/hqAV7EZniohILIFvAu0WKG+VHd8kLFh4lgPM tbEpSWTeeAdWSS7vyKrjVQcexQpuVvmZrA7Yix854ud3ASV0gK1XYaNu/vKDwTeOAwP+tdKH Pz3Kp6jgvlXU5SQtWwB3EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUySw71M7aXdi0L0i+W /Kn0jS/aO4qcy2zRfayiv684lWot380dFObfb8yfT9aw+cyDpAVr4RH4FqjwpF591HL2xa1u Ukli1QevibLUmhJ11d7yGdgzUImwxelkMKgWXo/UcL5/aJBQ7SQvAx+76wOHHimjUdlcA536 RR022DsZ1LSRvGgSTm/tDNEwpnj0yuvBMZ4KYuZlFkIP0jgYVq3MUiFYJuYeU9NTO/7JpiHP hlDcna6voTeVSGb2rBtm0qxNC3RHw8EhqPX0BH46WuonJrtWE8y1FdyN0Un38G+p54Q55Y5/ 7cOqAtkL1VVMcZYa90Ge9ES8qqDW7GRw7KLQupUB/aPbBCP2iIp4/84b0z6u3vcJsUzIEqkJ CES19cvX5aQTOYNSRP5uw+zvngehTMYd228LAu23FQgMyOeJP7dSueVVspj8ys5/0CH8yzYY fHBK5r
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHYVMDX0pnJlQhLrUiicQUgBCrtjqz6VpcAgABI4AA=
- Thread-topic: [PATCH v5 1/6] x86/debugger: Remove debugger_trap_entry()
On 21/04/2022 14:02, Jan Beulich wrote:
> On 20.04.2022 16:13, Andrew Cooper wrote:
>> From: Bobby Eshleman <bobby.eshleman@xxxxxxxxx>
>>
>> debugger_trap_entry() is unrelated to the other contents of debugger.h. It
>> is
>> a no-op for everything other than #DB/#BP, and for those it invokes guest
>> debugging (CONFIG_GDBSX) not host debugging (CONFIG_CRASH_DEBUG).
>>
>> Furthermore, the description of how to use debugger_trap_entry() is at best,
>> stale. It is not called from all exception paths,
> But on almost all (before this change) - the exception looks to be
> #NM.
>
>> and because the developer
>> is forced to modify Xen to perform debugging, editing debugger_trap_entry()
>> is
>> not the way one would efficiently go about diagnosing the problem.
> Shouldn't it be the remote end to request which exceptions it wants
> to be notified of? If so, removing the hook invocation isn't very
> helpful.
That's not part of the gdb remote protocol.
In normal conditions, gdb gets to see see anything which manifests as a
signal. It does not get to see anything which is resolved by the kernel
behind the scenes. #NM you've already identified, and most #PF's would
count too. Back in the 32bit days, Xen-induced #GP/#SS's for non-4G
segments would count too.
But in addition to filtering Xen's idea of "fixing up behind the
scenes", you also need to Xen to understand when to skip notifications
based on what a PV guest kernel can fix up, and this is getting even
further out of gdb's comfort zone.
debugger_trap_entry() is empty (WRT gdbstub) specifically because it's
description is nonsense in any practical debugging scenario. And lets
not start on the fact that the lack of ability to invoke
pv_event_inject() means that any fault from userspace will livelock
under debugging.
Deleting it is absolutely the right way forward, because a theoretical
future with someone wiring this up would have to start again from scratch.
Not that qualifies as a good reason in isolation, do_trap() contains
unreachable logic because the compiler can't figure out that #DB/#BP are
handled via alternative paths, and the gdbsx logic is dead.
~Andrew
|
