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

Re: [PATCH v3 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 28 Feb 2023 11:42:19 +0100
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Pfztsu1l5t88RbWV5BtA/ZRRTZ4ub6kpIsf2gMuFMT0=; b=aWWngwaZk9D52xFxgQq+UFl/0Jx2vVAD8fnBss2yGCuIAyGtyUHzYPeiwMFi1B6Ipa0rzmQq2CtsaD1eYJAYYDhkvB+tza4eOXt0n8RRAanAPfdUPIEMP0J1YcbJtLRAEzlwc5KZH8e6E9WaOvRZN2AQfUW2qsfGeJObJSd2YM54qi5q9w/PKERrNogEIMP00hhaC062DLWIz18hnSL8J4ASMQXzyi1SZS58e0e/EmxY9baAjdo0/DR8dLf9VXoLgjKSTLKssJu0xyZZp6yAsuecUj5en7Eiez97D+qSJM6HPO2xgyR89ROMTijvzST/s/tMliEn0p0CJnKdooxA6g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fVrdxL1cWt21PDu7GsabqAyhDDQCe7Lf6fG1t9kqhYlYrNQogsYqdju60GVhHmpAP3QyLYT6/cTTtp69KQ0UGrhwcxZhjCymH7RycoAzpDAPfeK4Z+g5DLKpKdO/J/bCY7jycILzWR1C3EzyL/YyF6pNbH6bgFLuSaxDdyC27P5L7pIvYsa8jM0UYfaoEigxsbGARX22A0QgAGXKJENvEIWzLPbOQWyR01xwldQf8LnwhPGoeAxCECiOiCQxSiiSX3HOTVH7+4Q31o1FRY/vFcCu3HdsEDIS5Q7Y5fzrDPNV3AE8e2U04BuQr6q6k3Y8Ys3DwMefUp3ZUomrEO5WEw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 28 Feb 2023 10:42:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.02.2023 11:30, Oleksii wrote:
> On Mon, 2023-02-27 at 15:23 +0100, Jan Beulich wrote:
>> On 24.02.2023 12:31, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/common/bug.c
>>> @@ -0,0 +1,109 @@
>>> +#include <xen/bug.h>
>>> +#include <xen/debugger.h>
>>> +#include <xen/errno.h>
>>> +#include <xen/kernel.h>
>>> +#include <xen/livepatch.h>
>>> +#include <xen/string.h>
>>> +#include <xen/types.h>
>>> +#include <xen/virtual_region.h>
>>> +
>>> +#include <asm/processor.h>
>>> +
>>> +/* Set default value for TRAP_invalid_op as it is defined only for
>>> X86 now */
>>> +#ifndef TRAP_invalid_op
>>> +#define TRAP_invalid_op 0
>>> +#endif
>>> +
>>> +int do_bug_frame(const struct cpu_user_regs *regs, unsigned long
>>> pc)
>>> +{
>>> +    const struct bug_frame *bug = NULL;
>>> +    const struct virtual_region *region;
>>> +    const char *prefix = "", *filename, *predicate;
>>> +    unsigned long fixup;
>>> +    unsigned int id = BUGFRAME_NR, lineno;
>>> +
>>> +    region = find_text_region(pc);
>>> +    if ( region )
>>> +    {
>>> +        for ( id = 0; id < BUGFRAME_NR; id++ )
>>> +        {
>>> +            const struct bug_frame *b;
>>> +            unsigned int i;
>>> +
>>> +            for ( i = 0, b = region->frame[id].bugs;
>>> +                  i < region->frame[id].n_bugs; b++, i++ )
>>> +            {
>>> +                if ( bug_loc(b) == pc )
>>> +                {
>>> +                    bug = b;
>>> +                    goto found;
>>> +                }
>>> +            }
>>> +        }
>>> +    }
>>> +
>>> + found:
>>> +    if ( !bug )
>>> +        return -EINVAL;
>>> +
>>> +    if ( id == BUGFRAME_run_fn )
>>> +    {
>>> +#ifdef BUG_FN_REG
>>> +        void (*fn)(const struct cpu_user_regs *) = (void *)regs-
>>>> BUG_FN_REG;
>>> +#else
>>> +        void (*fn)(const struct cpu_user_regs *) = bug_ptr(bug);
>>> +#endif
>>> +
>>> +        fn(regs);
>>> +
>>> +        return id;
>>> +    }
>>> +
>>> +    /* WARN, BUG or ASSERT: decode the filename pointer and line
>>> number. */
>>> +    filename = bug_ptr(bug);
>>> +    if ( !is_kernel(filename) && !is_patch(filename) )
>>> +        return -EINVAL;
>>> +    fixup = strlen(filename);
>>> +    if ( fixup > 50 )
>>> +    {
>>> +        filename += fixup - 47;
>>> +        prefix = "...";
>>> +    }
>>> +    lineno = bug_line(bug);
>>> +
>>> +    switch ( id )
>>> +    {
>>> +    case BUGFRAME_warn:
>>> +        printk("Xen WARN at %s%s:%d\n", prefix, filename, lineno);
>>> +        show_execution_state(regs);
>>> +
>>> +        return id;
>>> +
>>> +    case BUGFRAME_bug:
>>> +        printk("Xen BUG at %s%s:%d\n", prefix, filename, lineno);
>>> +
>>> +        if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
>>
>> TRAP_invalid_op is, as said, about to disappear on x86 as well. I
>> think
>> this construct wants abstracting by another asm/bug.h provided macro
>> (taking just regs).
>>
> Thanks for the link.
> 
> Nice idea to abstract 'debugger_trap_fatal(TRAP_invalid_op, regs)'.
> Actually we have to options here:
> 1. As you proposed abstract in <asm/bug.h>:
>    x86:  #define DEBUG_TRAP_FATAL(regs) debugger_trap_fatal(X86_EXC_GP,
> regs)
>    ARM: #define DEBUG_TRAP_FATAL(regs) 0
>    RISC-V: #define DEBUG_TRAP_FATAL(regs) 0
>   For ARM and RISC-V it doesn't use so we can skip the check if (
> DEBUG_TRAP_FATAL ).
> 
> 2. Abstract only TRAP_invalid_op in <asm/bug.h>
>   x86: #define TRAP_invalud_op X86_EXC_GP
>   RISC-V: #define TRAP_invalid_op 0
>   ARN: #define TRAP_invalid_op 0
>   
>   I am not sure if we have to provide real invalid opcodes for RISC-V
> and ARM as it looks like debug_trap_fatal() isn't used in ARM&RISC-V
> now.
> 
> Could you please suggest which one option is better?

I don't view 2 as a viable option. How an arch deals with invalid opcodes
is entirely arch-specific (including the naming). As to 1 - since we want
this solely for bug.c, I'd prefer if the wrapper macro's name would start
with BUG_, e.g. BUG_DEBUGGER_TRAP_FATAL() or BUG_TRAP_FATAL() or just
BUG_FATAL(). Further adding ARCH_ may also be wanted by other maintainers
(I'm neither pro nor con there).

Jan



 


Rackspace

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