From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Narayana Murty N" <nnmlinux@linux.ibm.com>,
<danielhb413@gmail.com>, <clg@kaod.org>,
<david@gibson.dropbear.id.au>, <groug@kaod.org>
Cc: <qemu-ppc@nongnu.org>, <qemu-devel@nongnu.org>, <farosas@suse.de>,
<npiggin@linux.ibm.com>, <vaibhav@linux.ibm.com>,
<harshpb@linux.ibm.com>, <sbhat@linux.ibm.com>
Subject: Re: [PATCH v3] target: ppc: Use MSR_HVB bit to get the target endianness for memory dump
Date: Mon, 29 May 2023 13:42:26 +1000 [thread overview]
Message-ID: <CSYG8RTMAB5O.2H9DDPSRE7JR0@wheely> (raw)
In-Reply-To: <20230522160242.37261-1-nnmlinux@linux.ibm.com>
On Tue May 23, 2023 at 2:02 AM AEST, Narayana Murty N wrote:
> Changes since V2:
> commit message modified as per feedbak from Nicholas Piggin.
> Changes since V1:
> https://lore.kernel.org/qemu-devel/20230420145055.10196-1-nnmlinux@linux.ibm.com/
> The approach to solve the issue was changed based on feedback from
> Fabiano Rosas on patch V1.
> ---
> target/ppc/arch_dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/ppc/arch_dump.c b/target/ppc/arch_dump.c
> index f58e6359d5..a8315659d9 100644
> --- a/target/ppc/arch_dump.c
> +++ b/target/ppc/arch_dump.c
> @@ -237,7 +237,7 @@ int cpu_get_dump_info(ArchDumpInfo *info,
> info->d_machine = PPC_ELF_MACHINE;
> info->d_class = ELFCLASS;
>
> - if (ppc_interrupts_little_endian(cpu, cpu->env.has_hv_mode)) {
> + if (ppc_interrupts_little_endian(cpu, !!(cpu->env.msr_mask & MSR_HVB))) {
> info->d_endian = ELFDATA2LSB;
> } else {
> info->d_endian = ELFDATA2MSB;
Oh, and now I see it cpu_get_dump_info just picks the first CPU to test
this! So a test that can change at runtime is surely not the right one.
If you use MSR[HV] then if you have a SMP machine that is doing a bunch
of things and you want to dump to debug the system, this will just
randomly give you a wrong-endian dump if CPU0 just happened to be
running some KVM guest.
I know HILE techically does change at runtime, but at least in practice
it is just boot (and maybe kexec or reboot) so that is the least worst
option. Part of the problem is perhaps the tools and commands aren't so
so suited to ppc's bi-endian nature.
But even ignoring all of that, let's say you have all the same endian
host and guest kernels and dump format... If you dump host memory then
you need host kernel and structures to debug guest kernel/image
(assuming crash or the person debugging it is smart enough to make sense
of it). So I don't see how you can sanely use the crash dump of host
memory with the guest kernel. I must still be missing something.
Thanks,
Nick
next prev parent reply other threads:[~2023-05-29 3:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 16:02 [PATCH v3] target: ppc: Use MSR_HVB bit to get the target endianness for memory dump Narayana Murty N
2023-05-22 18:20 ` Greg Kurz
2023-05-23 6:50 ` Narayana Murty N
2023-05-23 10:15 ` Greg Kurz
2023-06-23 7:25 ` Narayana Murty N
2023-05-23 10:22 ` Cédric Le Goater
2023-05-25 4:15 ` Narayana Murty N
2023-05-29 3:19 ` Nicholas Piggin
2023-05-29 3:42 ` Nicholas Piggin [this message]
2023-05-29 14:05 ` Fabiano Rosas
2023-06-05 9:33 ` Nicholas Piggin
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=CSYG8RTMAB5O.2H9DDPSRE7JR0@wheely \
--to=npiggin@gmail.com \
--cc=clg@kaod.org \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=farosas@suse.de \
--cc=groug@kaod.org \
--cc=harshpb@linux.ibm.com \
--cc=nnmlinux@linux.ibm.com \
--cc=npiggin@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sbhat@linux.ibm.com \
--cc=vaibhav@linux.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).