[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/4] build: use common stubs for debugger_trap_* functions if !CONFIG_CRASH_DEBUG


  • To: Bobby Eshleman <bobby.eshleman@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 14 Jul 2021 11:34:14 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-SenderADCheck; bh=6fLz+ocurCB/Q2SAWCMNn0ifUD8l/iJCo2rhwh0TUnM=; b=T/FcVecBFqFjv0eUyWRmeFT37mD8MwKi2ckEfL44Pn9wTYlUKpNhF2ldHJvZZcnFpmzWfUVBQibIDKrv058u+gNSuWmIrNcGPE1NSqpM78Nz9Zh9KGCNtQNsc9nwCYqgovQCraWOzKugIXEZNao3MKkUlMxkF3KTGhe/Gm5sYchHAPjNQiniQYY+YHER3MIfsQsNKXdECVFnnkirll9zeIb9PYwWWFwZF2LS2qOHKDla6JxMApe7IGBWUI+GjIvheaM1K6sDTwhvksA4gIfOMxycpZVV9xB0QU5+YFwHAW/iSfeKzD1P7hTk4G/xK+cxJLNqyiKD1uW+q42LhCtJLA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hW9AwonlhNDLaeBc2wlU1zD4tgAo1rbJ/R7opt/mF5k39Se+ZlDVUEzwJc8V/24//9HwNx2zh3+OIFNHua9ID5YW50/gv4ZgabU1p+tLCzN7B5uGlLreM7h9cUEZ/kV+aAqhsKhU0WH0+QfKXGRxMd93P826LCXDWobVMiaS0L4swG3pSdvlUvHUFTuD0DUZPlT5KpyR2v0/FJLrQAUsl7MphgK7gpTz21Ek5nqI8FOSqkVcjN1elqWAoKlfSaJebxFOiaAlKPvArc66qjWe1mvP+DddEBfaC8xXpuQLJd4yXx0mJ3kBApq1RG/xZy71a5Ep/1qzw121G7HwDMcrWA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 14 Jul 2021 09:34:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13.07.2021 03:59, Bobby Eshleman wrote:
> --- a/xen/arch/x86/gdbstub.c
> +++ b/xen/arch/x86/gdbstub.c
> @@ -18,7 +18,9 @@
>   * You should have received a copy of the GNU General Public License
>   * along with this program; If not, see <http://www.gnu.org/licenses/>.
>   */
> -#include <asm/debugger.h>
> +#include <asm/uaccess.h>
> +#include <xen/debugger.h>
> +#include <xen/gdbstub.h>

Here and in at least one more case below: Our usual pattern is to
have xen/ ones before asm/ ones. And (leaving aside existing
screwed code) ...

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -58,7 +58,7 @@
>  #include <asm/hvm/trace.h>
>  #include <asm/hap.h>
>  #include <asm/apic.h>
> -#include <asm/debugger.h>
> +#include <xen/debugger.h>
>  #include <asm/hvm/monitor.h>
>  #include <asm/monitor.h>
>  #include <asm/xstate.h>

... we also try to avoid introducing any mixture. Plus ...

> --- a/xen/arch/x86/hvm/vmx/realmode.c
> +++ b/xen/arch/x86/hvm/vmx/realmode.c
> @@ -14,7 +14,7 @@
>  #include <xen/sched.h>
>  #include <xen/paging.h>
>  #include <xen/softirq.h>
> -#include <asm/debugger.h>
> +#include <xen/debugger.h>

... we strive to have new insertions be sorted alphabetically. When
the existing section to insert into isn't suitably sorted yet, what
I normally do is try to find a place where at least the immediately
adjacent neighbors then fit the sorting goal.

Sorry, all just nits, but their scope is about the entire patch.

> --- /dev/null
> +++ b/xen/include/xen/debugger.h
> @@ -0,0 +1,81 @@
> +/******************************************************************************
> + * Generic hooks into arch-dependent Xen.

Now that you move this to be generic, I think it better also would
indeed be. See below.

> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see <http://www.gnu.org/licenses/>.
> + *
> + *

Nit: No double blank (comment) lines please.

> + * Each debugger should define three functions here:
> + *
> + * 1. debugger_trap_entry():
> + *  Called at start of any synchronous fault or trap, before any other work
> + *  is done. The idea is that if your debugger deliberately caused the trap
> + *  (e.g. to implement breakpoints or data watchpoints) then you can take
> + *  appropriate action and return a non-zero value to cause early exit from
> + *  the trap function.
> + *
> + * 2. debugger_trap_fatal():
> + *  Called when Xen is about to give up and crash. Typically you will use 
> this
> + *  hook to drop into a debug session. It can also be used to hook off
> + *  deliberately caused traps (which you then handle and return non-zero).
> + *
> + * 3. debugger_trap_immediate():
> + *  Called if we want to drop into a debugger now.  This is essentially the
> + *  same as debugger_trap_fatal, except that we use the current register 
> state
> + *  rather than the state which was in effect when we took the trap.
> + *  For example: if we're dying because of an unhandled exception, we call
> + *  debugger_trap_fatal; if we're dying because of a panic() we call
> + *  debugger_trap_immediate().
> + */
> +
> +#ifndef __XEN_DEBUGGER_H__
> +#define __XEN_DEBUGGER_H__
> +
> +/* Dummy value used by ARM stubs. */
> +#ifndef TRAP_invalid_op
> +# define TRAP_invalid_op 6
> +#endif

To avoid the need to introduce this, please flip ordering with the
subsequent patch.

> +#ifdef CONFIG_CRASH_DEBUG
> +
> +#include <asm/debugger.h>
> +
> +#else
> +
> +#include <asm/regs.h>
> +#include <asm/processor.h>
> +
> +static inline void domain_pause_for_debugger(void)
> +{
> +}
> +
> +static inline bool debugger_trap_fatal(
> +    unsigned int vector, const struct cpu_user_regs *regs)

I'm afraid the concept of a vector may not be arch-independent.

> +{
> +    return false;
> +}
> +
> +static inline void debugger_trap_immediate(void)
> +{
> +}
> +
> +static inline bool debugger_trap_entry(
> +    unsigned int vector, const struct cpu_user_regs *regs)
> +{
> +    return false;
> +}
> +
> +#endif /* CONFIG_CRASH_DEBUG */
> +
> +#ifdef CONFIG_GDBSX
> +unsigned int dbg_rw_mem(unsigned long gva, XEN_GUEST_HANDLE_PARAM(void) buf,
> +                        unsigned int len, domid_t domid, bool toaddr,
> +                        uint64_t pgd3);
> +#endif /* CONFIG_GDBSX */

I'm afraid this whole construct isn't arch independent, at least as long
as it has the "pgd3" parameter, documented elsewhere to mean "the value of
init_mm.pgd[3] in a PV guest" (whatever this really is in a 64-bit guest,
or in a non-Linux one).

But I don't see why this needs moving to common code in the first place:
It's x86-specific both on the producer and the consumer sides.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.