qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: Nicholas Piggin <npiggin@gmail.com>,
	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,
	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 11:05:06 -0300	[thread overview]
Message-ID: <87pm6js06l.fsf@suse.de> (raw)
In-Reply-To: <CSYG8RTMAB5O.2H9DDPSRE7JR0@wheely>

"Nicholas Piggin" <npiggin@gmail.com> writes:

> 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.
>

Not sure if you are just thinking out loud about MSR_HV or if you
mistook MSR_HVB for MSR_HV. But just in case:

The env->msr_mask is what tells us what MSR bits are supported for this
CPU, i.e. what features it contains. So MSR_HVB is not equivalent to
MSR[HV], but merely informs that this CPU knows about MSR_HV. We then
store that information at has_hv_mode. The MSR_HVB bit changes only
once (at cpu_ppc_set_vhyp), after we decide whether to use vhyp. So:

env->has_hv_mode == cpu supports HV mode;

MSR_HVB=1 == cpu supports HV mode AND we allow the OS to run with MSR_HV=1;

MSR_HVB=0 == cpu doesn't support HV mode OR
             cpu supports HV mode, but we don't allow the OS to run with
             MSR_HV=1 because QEMU is the HV (i.e. vhyp);

For the arch_dump code, passing (msr_mask & MSR_HVB) ends up meaning:
"can this OS ever run with MSR_HV=1?", which for emulated powernv would
be Yes and for pseries (incl. nested) would be No. So for emulated
powernv we always look at the emulated HILE and for pseries we always
look at LPCR_ILE.

> 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.
>

You're right, the QEMU instance that receives the qmp_dump_guest_memory
command should generate a memory dump of whatever OS is running in it at
a direct level.  So the endianness reported in the dump's ELF should
match the guest OS image ELF (roughly, there's -bios which doesn't
require an ELF).


  reply	other threads:[~2023-05-29 14:05 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
2023-05-29 14:05   ` Fabiano Rosas [this message]
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=87pm6js06l.fsf@suse.de \
    --to=farosas@suse.de \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=harshpb@linux.ibm.com \
    --cc=nnmlinux@linux.ibm.com \
    --cc=npiggin@gmail.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).