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

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


  • To: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 16 Mar 2023 10:52:11 +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=cW/4t6I4MqqHOOMnxOoHpsdSneQbOem+mTTcxPWTOK0=; b=BgKCeDCSKeTsGpyAI6X2vYnNSl7IkcWmfi5V3brcZxvoql2weuXdpBCjLh7nV/fz6FJ6kGCzKdcI7TMqwTEZpOatg1Czl/QGdkTwka2oSSdyq6v8mXZ7fhA9EQyg2tHqKfof1Q/z1qHi05f0tK2v/wdmRHOwJ3O5hb8Cted8Z/3CorT+kqzoL3syY41U10lb17M822r+u29njG7wEgJZMwysP5197RJ3jsjTlYux8O/rSftlXA2u5GBChWfA3Jjbch5VpZtUcAb1M7YHPY6Ev06YWKZE7C56XKpftvigqhTgp21QE817VNRzkgOjZj7tdkjyzNYHFPbht+kVWdDhcQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CQNDyNvfpy3FRO/YOewmLlbdecc62f8I1PmdDzhj+/Sc+l9ZR5LIvXOGmE6e/OL2zkcYpXUXaNEo8Vn9L29GKdS3XQtHRNVx2AsE6ne+cFlgbgIKvT7RDDlgtehz/nXvKeR6LV1m1qCgBGoYXJtuPOHoVK3ACedvIl7Z+KP2NZClV8MxOZ9Sqn4NoyOuGNf2xtDhX/O3uuciwev+7PiZsNEXRhM8zTP279s0hGqO+irgKN5d5vuVYUusBvlEYBeDvL6MlPlgxAAoOTrdnhJ0hFyfABU92lNrd3z+u0wYGX3+vWeixsrocMA20wW1oVVv/vPfdVukySsoXF5Yv/Ey5Q==
  • 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: Thu, 16 Mar 2023 09:52:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.03.2023 18:21, Oleksii Kurochko wrote:
> The following changes were made:
> * Make GENERIC_BUG_FRAME mandatory for X86
> * Update asm/bug.h using generic implementation in <xen/bug.h>
> * Update do_invalid_op using generic do_bug_frame()
> * Define BUG_DEBUGGER_TRAP_FATAL to debugger_trap_fatal(X86_EXC_GP,regs)
> * type of eip variable was changed to 'const void *'
> * add '#include <xen/debugger.h>'
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Changes in V8:
>  * move <xen/debuger.h> from <asm/bug.h> to <common/bug.c> to fix compilation 
> issue.
>    The following compilation issue occurs:
>      In file included from ./arch/x86/include/asm/smp.h:10,
>                  from ./include/xen/smp.h:4,
>                  from ./arch/x86/include/asm/processor.h:10,
>                  from ./arch/x86/include/asm/system.h:6,
>                  from ./arch/x86/include/asm/atomic.h:5,
>                  from ./include/xen/gdbstub.h:24,
>                  from ./arch/x86/include/asm/debugger.h:10,
>                  from ./include/xen/debugger.h:24,
>                  from ./arch/x86/include/asm/bug.h:7,
>                  from ./include/xen/bug.h:15,
>                  from ./include/xen/lib.h:27,
>                  from ./include/xen/perfc.h:6,
>                  from arch/x86/x86_64/asm-offsets.c:9:
>      ./include/xen/cpumask.h: In function 'cpumask_check':
>      ./include/xen/cpumask.h:84:9: error: implicit declaration of function 
> 'ASSERT' [-Werror=implicit-function-declaration]
>                     84 |         ASSERT(cpu < nr_cpu_ids);

I'm going to post a patch to address this specific failure. But something
similar may then surface elsewhere.

>    It happens in case when CONFIG_CRASH_DEBUG is enabled

I have to admit that I don't see the connection to CRASH_DEBUG: It's the
asm/atomic.h inclusion that's problematic afaics, yet that (needlessly)
happens outside the respective #ifdef in xen/gdbstub.h.

If another instance of this header interaction issue would surface despite
my to-be-posted patch, I'd be okay with going this route for the moment.
But I think the real issue here is xen/lib.h including xen/bug.h. Instead
of that, some stuff that's presently in xen/lib.h should instead move to
xen/bug.h, and the inclusion there be dropped. Any parties actually using
stuff from xen/bug.h (xen/lib.h then won't anymore) should then include
that header themselves.

Jan

> and the reason for that is when
>    <xen/lib.h> is included in <x86_64/asm-offsets.c>:9 the "layout" of 
> <xen/lib.h> would be
>    the following:
>      #include <xen/bug.h>:
>      #include <asm/bug.h>:
>      #include <xen/debugger.h>:
>          ....
>               cpumask.h:
>                      ....
>                     ASSERT(cpu < nr_cpu_ids);
>                   return cpu;
>                      .... 
>      ....
>      #define ASSERT ...
>      ....
>    Thereby ASSERT is defined after it was used in <xen/cpumask.h>.




 


Rackspace

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