On Sat Apr 29, 2023 at 12:30 AM AEST, Fabiano Rosas wrote:
Vaibhav Jain <vaibhav@linux.ibm.com> writes:
Hi Fabiano,
Thanks for looking into this patch and apologies for the delayed reponse.
Fabiano Rosas <farosas@suse.de> writes:
Narayana Murty N <nnmlinux@linux.ibm.com> writes:
On PPC64 the HILE(Hypervisor Interrupt Little Endian) bit in HID-0
register needs to be initialized as per isa 3.0b[1] section
2.10. This bit gets copied to the MSR_LE when handling interrupts that
are handled in HV mode to establish the Endianess mode of the interrupt
handler.
Qemu's ppc_interrupts_little_endian() depends on HILE to determine Host
endianness which is then used to determine the endianess of the guest dump.
Not quite. We use the interrupt endianness as a proxy to guest
endianness to avoid reading MSR_LE at an inopportune moment when the
guest is switching endianness.
Agreed
This is not dependent on host
endianness. The HILE check is used when taking a memory dump of a
HV-capable machine such as the emulated powernv.
I think one concern which the patch tries to address is the guest memorydump file
generated of a BigEndian(BE) guest on a LittleEndian(LE) host is not readable on
the same LE host since 'crash' doesnt support cross endianess
dumps. Also even for a LE guest on LE host the memory dumps are marked as BE
making it not possible to analyze any guest memory dumps on the host.
>From QEMU's perspective there's no "host" in this equation. We'll
generate a BE dump for a BE guest and a LE dump for a LE guest. Anything
different is a bug in QEMU (as the one this patch addresses).
I'm trying to figure out what's going on here. On one hand we are
creating a dump for/in the host. The dump is just a format that
describes register metadata, the same values can be represented just
fine with either endian. Memory has no endianness (without data
structures). So from that perspective, we do want to dump host endian
format.
OTOH crash could be taught foreign-endianness in which case the
endianness of the ELF file could be useful metadata about the
target I suppose. But ILE != MSR[LE] at any given time.
ILE seems like a half way house. It doesn't always give host endian
dumps so crash won't always work. It doesn't always give the machine
operating mode either. So why is it better to take guest ILE mode than
HV ILE mode?
I guess the first thing we need is a better and precise description of
the problem and the desired resolution. PPC64 has powernv and pseries,
both of which can support guests in various ways (PR, HV, nested HV),
and then when running guests the target itself also functions as a host,
so need to make all that unambiguous and use correct terminoogy in
the changelog.
However setting the HILE based on host endianess of qemu might not be
the right way to fix this problem. Based on an off mailing list discussion
with Narayana, he is working on another patch which doesnt set HILE
based on host endianess. However the problem seems to be stemming from
fact that qemu on KVM is using the HILE to set up the endianess of
memory-dump elf and since its not setup correctly the memory dumps are
in wrong endianess.
I think the actual issue might be that we're calling
ppc_interrupts_little_endian with hv=true for the dump.
Yes, that is currently the case with cpu_get_dump_info(). Excerpt from
that function below that sets the endianess of the dump:
if (ppc_interrupts_little_endian(cpu, cpu->env.has_hv_mode)) {
This should probably be looking at cpu->vhyp or MSR_HVB since
has_hv_mode will not change after we init the cpu.
info->d_endian = ELFDATA2LSB;
} else {
info->d_endian = ELFDATA2MSB;
}
for pseries kvm guest cpu->env.has_hv_mode is already set hence
ppc_interrupts_little_endian() assumes its running in 'hv' mode. The new
patch from Narayana will be addressing this.
Currently the HILE bit is never set in the HID0 register even if the
qemu is running in Little-Endian mode. This causes the guest dumps to be
always taken in Big-Endian byte ordering. A guest memory dump of a
Little-Endian guest running on Little-Endian qemu guest fails with the
crash tool as illustrated below:
Could you describe in more detail what is your setup? Specifically
whether both guests are running TCG or KVM (info kvm) and the state of
the nested-hv capability in QEMU command line.
Currently the issue is seen with any pseries KVM guest running on a PowerNV host.
Okay originally I thought you were talking about a powernv target
that is running a pseries guest and dumping that. But after re-reading, I
think you're talking about dumping a pseries target?