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

Re: [PATCH v5 4/4] xen/x86: switch x86 to use generic implemetation of bug.h


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Mar 2023 13:59:52 +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=TwF6sOp9E35LXOG1MmbNB8Hk+aAUK/sxyqHptmkkULU=; b=iNV9Uzxcy3ORMEVBpKSA50IVp9qvb4flJRx4ydPN8kCKaLphDAEcq5pssypNU191eDij30sxrJvDHHRtN121rWBBq9wOfqLTjJX7pjO1vyjM7ykFC4+Zj2I6UgSgIAPe+L5SSeTlwjTImXeXo5rM+uiq27EpYmwV73abAIliJsaI5LKQ9MpnbCaf5Q05Ead13IrDSA4eQqA32FvfHMKBGMj9Xv3srKi4j8o4YE+Gaim1FoZXJ3SSLmWU550cKdokggNMD4CqHRdnuPQXyYyxKw4BFwFziRG1GgbJDUvwoDuDjbMknnAIbJtR97Lb9kNeySPiC8K+RgncJ7BiskFwPw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=juubP/Y/sD6tGGGY9Zgp0OglDeTppDmGGs51+y/e++xamogoLMyiYXhqUBW0zkgra6GuaWbS59XQ1nV/6Ff7hFv66xgA7fL4oBYH8kkcqKjE3QpITfzRQXgCWkCQhSlIeIYmUoKwzTSkqINVjTCKrBG6ZPNZQvJ1kkDmFXvCPcRrKBEmDZnfqaWJv7+85H7HEKERoOT7mhNO3EwFXjFMea/MorqEm5A7zh9nytoFiK34J74Oslz4+jRWzQEuiVRT8/PB+vNXRWe7yH9ZughUTDPbPKnqWn0nsqc50dlUtTMjq8PY5nrzh1ax6AASR1g3gMbFVn3+IY+ZI4UU5EMJhQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Julien Grall <julien@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 07 Mar 2023 13:00:03 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.03.2023 13:52, Oleksii wrote:
> On Mon, 2023-03-06 at 11:36 +0100, Jan Beulich wrote:
>> On 03.03.2023 11:38, Oleksii Kurochko wrote:
>>> --- a/xen/arch/x86/include/asm/bug.h
>>> +++ b/xen/arch/x86/include/asm/bug.h
>>> @@ -1,79 +1,12 @@
>>>  #ifndef __X86_BUG_H__
>>>  #define __X86_BUG_H__
>>>  
>>> -#define BUG_DISP_WIDTH    24
>>> -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>>> -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
>>> +#define BUG_DEBUGGER_TRAP_FATAL(regs)
>>> debugger_trap_fatal(X86_EXC_GP,regs)
>>
>> Along the lines of a comment on an earlier patch, please move this
>> ...
>>
>>>  #ifndef __ASSEMBLY__
>>
>> ... into the thus guarded section.
> But it was defined there before the patch series and these definies are
> used in "#else /* !__ASSEMBLY__ */"

Since you use plural, maybe a misunderstanding? My comment was solely
on the line you add; the removed lines are there merely as context.

>>> @@ -1166,12 +1167,9 @@ void cpuid_hypervisor_leaves(const struct
>>> vcpu *v, uint32_t leaf,
>>>  
>>>  void do_invalid_op(struct cpu_user_regs *regs)
>>>  {
>>> -    const struct bug_frame *bug = NULL;
>>>      u8 bug_insn[2];
>>> -    const char *prefix = "", *filename, *predicate, *eip = (char
>>> *)regs->rip;
>>> -    unsigned long fixup;
>>> -    int id = -1, lineno;
>>> -    const struct virtual_region *region;
>>> +    const char *eip = (char *)regs->rip;
>>
>> I realize "char" was used before, but now that this is all on its
>> own,
>> can this at least become "unsigned char", but yet better "void"?
> If we change it to "void" shouldn't it require additional casts here (
> which is not nice ):
>        eip += sizeof(bug_insn);

Arithmetic on pointers to void is a GNU extension which we make
heavy use of all over the hypervisor.

>>>      switch ( id )
>>>      {
>>> +    case BUGFRAME_run_fn:
>>>      case BUGFRAME_warn:
>>> -        printk("Xen WARN at %s%s:%d\n", prefix, filename, lineno);
>>> -        show_execution_state(regs);
>>>          fixup_exception_return(regs, (unsigned long)eip);
>>>          return;
>>> -
>>> -    case BUGFRAME_bug:
>>> -        printk("Xen BUG at %s%s:%d\n", prefix, filename, lineno);
>>> -
>>> -        if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
>>> -            return;
>>
>> This and ...
>>
>>> -        show_execution_state(regs);
>>> -        panic("Xen BUG at %s%s:%d\n", prefix, filename, lineno);
>>> -
>>> -    case BUGFRAME_assert:
>>> -        /* ASSERT: decode the predicate string pointer. */
>>> -        predicate = bug_msg(bug);
>>> -        if ( !is_kernel(predicate) && !is_patch(predicate) )
>>> -            predicate = "<unknown>";
>>> -
>>> -        printk("Assertion '%s' failed at %s%s:%d\n",
>>> -               predicate, prefix, filename, lineno);
>>> -
>>> -        if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
>>> -            return;
>>
>> ... this return look to have no proper representation in the new
>> logic; both cases fall through to ...
>>
>>> -        show_execution_state(regs);
>>> -        panic("Assertion '%s' failed at %s%s:%d\n",
>>> -              predicate, prefix, filename, lineno);
>>>      }
>>>  
>>>   die:
>>
>> ... here now, which is an unwanted functional change.
> Oh, you are right. So then in case we have correct id it is needed to
> do only return:
>     switch ( id )
>     {
>     case BUGFRAME_run_fn:
>     case BUGFRAME_warn:
>         fixup_exception_return(regs, (unsigned long)eip);
>         break;
>     }
> 
>     return;

Except the "return" needs to remain inside the switch; unrecognized id
values should still fall through to the "die" label.

Jan



 


Rackspace

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