[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231004195001.76a57417@gandalf.local.home>
Date: Wed, 4 Oct 2023 19:50:01 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Dan Raymond <raymod2@...il.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
x86@...nel.org, linux-serial <linux-serial@...r.kernel.org>,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, peterz@...radead.org,
andriy.shevchenko@...ux.intel.com, quic_saipraka@...cinc.com
Subject: Re: [PATCH v3] arch/x86: port I/O tracing on x86
On Wed, 4 Oct 2023 16:54:20 -0600
Dan Raymond <raymod2@...il.com> wrote:
> With one exception io.h is included from boot.h or misc.h which is where
> the include guards are defined:
>
> # find arch/x86/boot -type f -print0 | xargs -0 grep "#include.*[^a-z]io\.h"
> arch/x86/boot/boot.h:#include "io.h"
> arch/x86/boot/compressed/misc.h:#include "../io.h"
> arch/x86/boot/compressed/tdx.c:#include "../io.h"
> arch/x86/boot/io.h:#include <asm/shared/io.h>
>
> I agree this is fragile but the problem is not confined to this patch.
> If I add a call to rdmsr() or wrmsr() in arch/x86/boot/compressed/misc.c
> I get the same compiler error. It has something to do with the inline
> assembly inside arch/x86/include/asm/jump_label.h.
Doesn't arch/x86/boot/* code create an image that is separate from the core
vmlinux? That is, that code doesn't implement jump label logic nor sections.
>
> I've copied Steven Rostedt who is the maintainer of tracefs to see if he
> has any comment. I just noticed arch/x86/boot/msr.h and I see that it
> redefines rdmsr() and wrmsr() and omits the tracepoints. A comment there
> explains:
>
> /*
> * The kernel proper already defines rdmsr()/wrmsr(), but they are not for the
> * boot kernel since they rely on tracepoint/exception handling infrastructure
> * that's not available here.
> */
>
> We could do something similar for inb()/outb() and redefine them in
> arch/x86/boot/io.h instead of including <asm/shared/io.h> there.
That would be a saner approach.
-- Steve
Powered by blists - more mailing lists