Re: [Qemu-devel] [PATCH v5] target-ppc: ppc64 target's virtio can be either endian

[Alexander Graf]

Am 21.04.2014 um 10:55 schrieb Bharata B Rao <address@hidden>:

On Mon, Apr 21, 2014 at 1:26 PM, Alexander Graf <address@hidden> wrote:

Am 21.04.2014 um 06:16 schrieb Bharata B Rao <address@hidden>:

On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <address@hidden> wrote:

+
+#if !defined(CONFIG_USER_ONLY)
+bool virtio_is_big_endian(void)
+{
+    PowerPCCPU *cp = POWERPC_CPU(first_cpu);
+    CPUPPCState *env = &cp->env;
+
+    /* NOTE: booke uses the same number for another unrelated spr.
+     */
+    if (strcmp(env->spr_cb[SPR_LPCR].name, "LPCR")) {
+        return TARGET_WORDS_BIGENDIAN;
+    } else {
+        return !(env->spr[SPR_LPCR] & LPCR_ILE);
+    }
+}
+#endif

I am adding crash support for little endian ppc64 guests and I realized that the above code needs to be re-used in target-ppc/arch_dump.c:cpu_get_dump_info() to set the endianness.

Wouldn't it make more sense to treat dumps like gdb and set the endianness depending on MSR_LE?

Since we are talking about guest system dumps here and going by what Ben says here (http://article.gmane.org/gmane.comp.emulators.qemu/227201), it appears that using LPCR_ILE would be appropriate.

Take the example that Ben raised - lx86 on be. When you create a dump, do you want to analyze lx86 or Linux beneath? For virtio the answer is easy. For crash dumps not so much.

I think the most sensible thing to do is to base on msr_le and allow the user to override our clever decision. If you feel strongly for the ILE approach, I won't refuse that either though.

That said, in case you do want to go with the ILE approach, make sure you don't call the *virtio specific* cpu callback and that you stay compatible with non-ibm cpus.

Alex