From: David Woodhouse <dwmw2@infradead.org>
To: "H. Peter Anvin" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"jpoimboe@kernel.org" <jpoimboe@kernel.org>
Cc: "horms@kernel.org" <horms@kernel.org>,
"x86@kernel.org" <x86@kernel.org>, "bp@alien8.de" <bp@alien8.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"kai.huang@intel.com" <kai.huang@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [RFC PATCH 6/7] x86/kexec: Debugging support: Dump registers on exception
Date: Tue, 05 Nov 2024 18:43:44 -0800 [thread overview]
Message-ID: <10f2dec7afbbff6570007495185ce1c4144e446b.camel@infradead.org> (raw)
In-Reply-To: <b66cd5ca-aae4-48eb-a0ba-2d1d4e53f810@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]
On Tue, 2024-11-05 at 13:37 -0800, H. Peter Anvin wrote:
>
> Looking at your code, you have a much bigger problem here:
>
> +/*
> + * This allows other types of serial ports to be used.
> + * - %al: Character to be printed (no clobber %rax)
> + * - %rdx: MMIO address or port.
> + */
> +.macro pr_char
> + outb %al, %dx
> +.endm
> +
>
> This will overflow your UART buffer very quickly since you are now
> dumping a whole bunch of data. The URT buffer -- if you even have one
> and it is enabled -- is only 16 bytes in a standard 16550A UART. In
> older UARTs (or emulated older UARTs) you might not have a buffer at
> all. To print more than a handful of bytes, you need to poll for the
> THRE bit=1 (bit 5 of register 5).
Emulated UARTs are generally fine because they don't really emulate the
buffer at all. And when I originally wrote this it was purely a hack to
debug an issue for myself, and used a different type of logging device
altogether.
But yeah, if this were to be used on bare metal 16550A it would indeed
need to wait for space in the FIFO/THR.
> What is the point of writing this code in assembly in the first place? A
> much more logical thing to do is to just push the registers you haven't
> pushed already onto the stack and call a C function to do the actual
> dumping? It isn't like it is in any shape, way or form performance critical.
If we fix it up to use a proper linker script, that's slightly more
feasible. As things stand, it's only really possible to do it in the
existing asm file.
And it's only the core of the exception handler "function" which could
be moved out to C; it didn't seem particularly worth bothering. Would
be nice to have the IDT generated from C code *before* calling
relocate_kernel() instead of inside relocate_kernel itself, perhaps,
but I was also trying to keep the #define DEBUG version of the code
fairly self-contained.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
next prev parent reply other threads:[~2024-11-06 2:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-03 5:35 [RFC PATCH 0/7] x86/kexec: Add exception handling for relocate_kernel David Woodhouse
2024-11-03 5:35 ` [RFC PATCH 1/7] x86/kexec: Clean up and document register use in relocate_kernel_64.S David Woodhouse
2024-11-05 10:00 ` Huang, Kai
2024-11-05 20:17 ` David Woodhouse
2024-11-03 5:35 ` [RFC PATCH 2/7] x86/kexec: Use named labels in swap_pages " David Woodhouse
2024-11-05 10:01 ` Huang, Kai
2024-11-03 5:35 ` [RFC PATCH 3/7] x86/kexec: Only swap pages for preserve_context mode David Woodhouse
2024-11-03 5:35 ` [RFC PATCH 4/7] x86/kexec: Debugging support: load a GDT David Woodhouse
2024-11-03 5:35 ` [RFC PATCH 5/7] x86/kexec: Debugging support: Load an IDT and basic exception entry points David Woodhouse
2024-11-03 5:35 ` [RFC PATCH 6/7] x86/kexec: Debugging support: Dump registers on exception David Woodhouse
2024-11-05 20:38 ` Woodhouse, David
2024-11-05 20:50 ` H. Peter Anvin
2024-11-05 21:29 ` David Woodhouse
2024-11-05 22:08 ` H. Peter Anvin
2024-11-05 21:37 ` H. Peter Anvin
2024-11-05 21:58 ` H. Peter Anvin
2024-11-05 22:27 ` H. Peter Anvin
2024-11-05 22:57 ` H. Peter Anvin
2024-11-14 7:40 ` Andy Shevchenko
2024-11-06 2:43 ` David Woodhouse [this message]
2024-11-06 2:47 ` H. Peter Anvin
2024-11-06 3:07 ` David Woodhouse
2024-11-08 5:21 ` David Woodhouse
2024-11-08 5:22 ` [RFC PATCH 1/2] x86/kexec: Use linker script for relocate_kernel page layout David Woodhouse
2024-11-08 5:22 ` [RFC PATCH 2/2] x86/kexec: Add data section to relocate_kernel David Woodhouse
2024-11-08 5:35 ` David Woodhouse
2024-11-08 11:26 ` H. Peter Anvin
2024-11-08 12:29 ` David Woodhouse
2024-11-12 8:44 ` David Woodhouse
2024-11-12 10:14 ` Peter Zijlstra
2024-11-12 10:45 ` David Woodhouse
2024-11-14 1:46 ` jpoimboe
2024-11-03 5:35 ` [RFC PATCH 7/7] [DO NOT MERGE] x86/kexec: enable DEBUG David Woodhouse
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=10f2dec7afbbff6570007495185ce1c4144e446b.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=horms@kernel.org \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kexec@lists.infradead.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.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®