mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dan Raymond <draymond@foxvalley.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com
Subject: Re: [PATCH v1] arch/x86: port I/O tracing on x86
Date: Thu, 21 Sep 2023 11:07:50 -0600	[thread overview]
Message-ID: <bc40a671-29f6-b897-1562-8dd48a01cbbf@foxvalley.net> (raw)
In-Reply-To: <818a0e52-2727-5bf1-0081-53322630e9bc@foxvalley.net>

On 9/19/2023 4:43 PM, Dan Raymond wrote:
> On 9/19/2023 3:31 PM, Dan Raymond wrote:
>> On 9/19/2023 3:12 PM, Peter Zijlstra wrote:
>>>>> This means I can no longer use early_console->write() to print to my
>>>>> early_serial_console.
>>>>
>>>> Why not?  Did you try it?
>>>
>>> I have tried debugging the kernel for the last 15+ years. The only
>>> reliable way to get something out of the machine is outb on the serial
>>> port. Anything else is a waste of time..
>>>
>>> Adding tracing to it (which relies on RCU, which might not be alive at
>>> this point) which might itself be the problem, is a total no-go.
>>>
>>> You do not wreck early_serial_console.
>>
>> But you didn't try my patch to see if it "wrecks" early_serial_console.
>> I doubt it has any impact there because it does not get compiled into
>> boot code.  Notice the BOOT_COMPRESSED_MISC_H and BOOT_BOOT_H checks.
>>
>> I don't understand your general objection.  The kernel already has
>> tracing for memory mapped I/O which includes serial ports.  This patch
>> just extends that to include port I/O.
> 
> Another point: The tracing infrastructure uses RCU for management of
> trace buffers.  If you don't explicitly enable portio tracing nothing
> will get written to the trace buffers.  Nothing extra will be done
> during outb() except for a quick check to see that tracing is disabled.
> This check took only a few clock cycles on average during my testing.
> This should be fine even during early boot.

Tracing is enabled/disabled by modifying the code segment at runtime.
To demonstrate this point:

# grep do_trace_portio_write /proc/kallsyms
c13800d0 T do_trace_portio_write
c1915fd0 r __ksymtab_do_trace_portio_write
c19231b5 r __kstrtabns_do_trace_portio_write
c192ca4d r __kstrtab_do_trace_portio_write

# hexdump -C -s 0x013800d0 /dev/mem | head -1
013800d0  3e 8d 74 26 00 c3 8d b4  26 00 00 00 00 8d 76 00  |>.t&....&.....v.|

# echo 1 > /sys/kernel/tracing/events/portio/portio_write/enable
# hexdump -C -s 0x013800d0 /dev/mem | head -1
013800d0  e9 0b 00 00 00 c3 8d b4  26 00 00 00 00 8d 76 00  |........&.....v.|

Disassembling this shows what changed:

# echo "0: 3e 8d 74 26 00 c3" | xxd -r > a.out
# objdump -D -b binary -m i386
...
00000000 <.data>:
   0:   3e 8d 74 26 00          lea    %ds:0x0(%esi,%eiz,1),%esi
   5:   c3                      ret

# echo "0: e9 0b 00 00 00 c3" | xxd -r > a.out
# objdump -D -b binary -m i386
...
00000000 <.data>:
   0:   e9 0b 00 00 00          jmp    0x10
   5:   c3                      ret

The 'lea' instruction is a nop so when tracing is disabled this function
does nothing.  When tracing is enabled the 'jmp' instruction transfers
control past the 'ret' instruction to the tracing logic.

  reply	other threads:[~2023-09-21 21:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 17:55 Dan Raymond
2023-09-19 17:26 ` kernel test robot
2023-09-19 19:30   ` Dan Raymond
2023-09-20  0:31     ` Dan Raymond
2023-09-19 17:26 ` kernel test robot
2023-09-19 19:43 ` Peter Zijlstra
2023-09-19 19:56   ` Dan Raymond
2023-09-19 21:12     ` Peter Zijlstra
2023-09-19 21:31       ` Dan Raymond
2023-09-19 22:43         ` Dan Raymond
2023-09-21 17:07           ` Dan Raymond [this message]
2023-09-25 21:10 ` Dan Raymond

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc40a671-29f6-b897-1562-8dd48a01cbbf@foxvalley.net \
    --to=draymond@foxvalley.net \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®