| Message ID | 20170911110037.6567-1-lvivier@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | hmp: fix "dump-quest-memory" segfault (ppc) | expand |
On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > fixes the problem for i386, do the same for ppc. What about all the other targets QEMU supports ? Have you checked if they are similarly affected, as we don't want to wait another 6 months to get a bug report that s390 or aarch64 crash in exactly the same way too. Regards, Daniel
On Mon, 11 Sep 2017 13:00:37 +0200 Laurent Vivier <lvivier@redhat.com> wrote: > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > fixes the problem for i386, do the same for ppc. > > Running QEMU with > qemu-system-ppc64 -M none -nographic -m 256 > and executing > dump-guest-memory /dev/null 0 8192 > results in segfault > > Fix by checking if we have CPU. > > Signed-off-by: Laurent Vivier <lvivier@redhat.com> > --- Reviewed-by: Greg Kurz <groug@kaod.org> > target/ppc/arch_dump.c | 17 +++++++++++------ > 1 file changed, 11 insertions(+), 6 deletions(-) > > diff --git a/target/ppc/arch_dump.c b/target/ppc/arch_dump.c > index 8e9397aa58..dcb7b19950 100644 > --- a/target/ppc/arch_dump.c > +++ b/target/ppc/arch_dump.c > @@ -224,17 +224,22 @@ typedef struct NoteFuncDescStruct NoteFuncDesc; > int cpu_get_dump_info(ArchDumpInfo *info, > const struct GuestPhysBlockList *guest_phys_blocks) > { > - PowerPCCPU *cpu = POWERPC_CPU(first_cpu); > - PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); > - > info->d_machine = PPC_ELF_MACHINE; > info->d_class = ELFCLASS; > > - if ((*pcc->interrupts_big_endian)(cpu)) { > - info->d_endian = ELFDATA2MSB; > + if (first_cpu) { > + PowerPCCPU *cpu = POWERPC_CPU(first_cpu); > + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); > + > + if ((*pcc->interrupts_big_endian)(cpu)) { > + info->d_endian = ELFDATA2MSB; > + } else { > + info->d_endian = ELFDATA2LSB; > + } > } else { > - info->d_endian = ELFDATA2LSB; > + info->d_endian = ELFDATA2MSB; > } > + > /* 64KB is the max page size for pseries kernel */ > if (strncmp(object_get_typename(qdev_get_machine()), > "pseries-", 8) == 0) {
On 11/09/2017 13:06, Daniel P. Berrange wrote: > On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: >> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) >> fixes the problem for i386, do the same for ppc. > > What about all the other targets QEMU supports ? Have you checked if they > are similarly affected, as we don't want to wait another 6 months to get a > bug report that s390 or aarch64 crash in exactly the same way too. s390 works fine, but aarch64 needs the same kind of fix. Thanks, Laurent
On Mon, 11 Sep 2017 12:06:15 +0100 "Daniel P. Berrange" <berrange@redhat.com> wrote: > On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: > > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > > fixes the problem for i386, do the same for ppc. > > What about all the other targets QEMU supports ? Have you checked if they > are similarly affected, as we don't want to wait another 6 months to get a > bug report that s390 or aarch64 crash in exactly the same way too. This patch actually prompted me to check s390, and the mentioned command line works fine. However, if we start a qemu with no guest memory defined and then call dump-guest-memory without filtering, we get a core dump instead of a guest dump (s390x or x86_64, machine none). I can take a stab at fixing that, unless someone beats me to it.
On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: > On Mon, 11 Sep 2017 12:06:15 +0100 > "Daniel P. Berrange" <berrange@redhat.com> wrote: > > > On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: > > > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > > > fixes the problem for i386, do the same for ppc. > > > > What about all the other targets QEMU supports ? Have you checked if they > > are similarly affected, as we don't want to wait another 6 months to get a > > bug report that s390 or aarch64 crash in exactly the same way too. > > This patch actually prompted me to check s390, and the mentioned > command line works fine. > > However, if we start a qemu with no guest memory defined and then call > dump-guest-memory without filtering, we get a core dump instead of a > guest dump (s390x or x86_64, machine none). > > I can take a stab at fixing that, unless someone beats me to it. I wonder if someone wants to write a qtest job to run dump-guest-memory across all machine types, on all targets. Seems we have enough crashiness in this code to make it worthwhile to test Regards, Daniel
* Daniel P. Berrange (berrange@redhat.com) wrote: > On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: > > On Mon, 11 Sep 2017 12:06:15 +0100 > > "Daniel P. Berrange" <berrange@redhat.com> wrote: > > > > > On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: > > > > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > > > > fixes the problem for i386, do the same for ppc. > > > > > > What about all the other targets QEMU supports ? Have you checked if they > > > are similarly affected, as we don't want to wait another 6 months to get a > > > bug report that s390 or aarch64 crash in exactly the same way too. > > > > This patch actually prompted me to check s390, and the mentioned > > command line works fine. > > > > However, if we start a qemu with no guest memory defined and then call > > dump-guest-memory without filtering, we get a core dump instead of a > > guest dump (s390x or x86_64, machine none). > > > > I can take a stab at fixing that, unless someone beats me to it. > > I wonder if someone wants to write a qtest job to run dump-guest-memory > across all machine types, on all targets. Seems we have enough crashiness > in this code to make it worthwhile to test We do have - that's how we found this case; it's part of test-hmp. Dave > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 11/09/2017 14:04, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: >> On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: >>> On Mon, 11 Sep 2017 12:06:15 +0100 >>> "Daniel P. Berrange" <berrange@redhat.com> wrote: >>> >>>> On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: >>>>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) >>>>> fixes the problem for i386, do the same for ppc. >>>> >>>> What about all the other targets QEMU supports ? Have you checked if they >>>> are similarly affected, as we don't want to wait another 6 months to get a >>>> bug report that s390 or aarch64 crash in exactly the same way too. >>> >>> This patch actually prompted me to check s390, and the mentioned >>> command line works fine. >>> >>> However, if we start a qemu with no guest memory defined and then call >>> dump-guest-memory without filtering, we get a core dump instead of a >>> guest dump (s390x or x86_64, machine none). >>> >>> I can take a stab at fixing that, unless someone beats me to it. >> >> I wonder if someone wants to write a qtest job to run dump-guest-memory >> across all machine types, on all targets. Seems we have enough crashiness >> in this code to make it worthwhile to test > > We do have - that's how we found this case; it's part of test-hmp. The test-hmp runs by default with 0 MB of memory, the problem can only be found with some memory added to the machine. Perhaps we can simply update the test to add memory? BTW, I'm not sure it is really useful to dump memory of a machine without CPU. Laurent
On Mon, Sep 11, 2017 at 02:10:14PM +0200, Laurent Vivier wrote: > On 11/09/2017 14:04, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrange (berrange@redhat.com) wrote: > >> On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: > >>> On Mon, 11 Sep 2017 12:06:15 +0100 > >>> "Daniel P. Berrange" <berrange@redhat.com> wrote: > >>> > >>>> On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: > >>>>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > >>>>> fixes the problem for i386, do the same for ppc. > >>>> > >>>> What about all the other targets QEMU supports ? Have you checked if they > >>>> are similarly affected, as we don't want to wait another 6 months to get a > >>>> bug report that s390 or aarch64 crash in exactly the same way too. > >>> > >>> This patch actually prompted me to check s390, and the mentioned > >>> command line works fine. > >>> > >>> However, if we start a qemu with no guest memory defined and then call > >>> dump-guest-memory without filtering, we get a core dump instead of a > >>> guest dump (s390x or x86_64, machine none). > >>> > >>> I can take a stab at fixing that, unless someone beats me to it. > >> > >> I wonder if someone wants to write a qtest job to run dump-guest-memory > >> across all machine types, on all targets. Seems we have enough crashiness > >> in this code to make it worthwhile to test > > > > We do have - that's how we found this case; it's part of test-hmp. > > The test-hmp runs by default with 0 MB of memory, the problem can only > be found with some memory added to the machine. > > Perhaps we can simply update the test to add memory? Probably best to run it twice, 0MB and with say 2MB, as they're both fairly magic values. Regards, Daniel
On 11/09/2017 14:13, Daniel P. Berrange wrote: > On Mon, Sep 11, 2017 at 02:10:14PM +0200, Laurent Vivier wrote: >> On 11/09/2017 14:04, Dr. David Alan Gilbert wrote: >>> * Daniel P. Berrange (berrange@redhat.com) wrote: >>>> On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: >>>>> On Mon, 11 Sep 2017 12:06:15 +0100 >>>>> "Daniel P. Berrange" <berrange@redhat.com> wrote: >>>>> >>>>>> On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: >>>>>>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) >>>>>>> fixes the problem for i386, do the same for ppc. >>>>>> >>>>>> What about all the other targets QEMU supports ? Have you checked if they >>>>>> are similarly affected, as we don't want to wait another 6 months to get a >>>>>> bug report that s390 or aarch64 crash in exactly the same way too. >>>>> >>>>> This patch actually prompted me to check s390, and the mentioned >>>>> command line works fine. >>>>> >>>>> However, if we start a qemu with no guest memory defined and then call >>>>> dump-guest-memory without filtering, we get a core dump instead of a >>>>> guest dump (s390x or x86_64, machine none). >>>>> >>>>> I can take a stab at fixing that, unless someone beats me to it. >>>> >>>> I wonder if someone wants to write a qtest job to run dump-guest-memory >>>> across all machine types, on all targets. Seems we have enough crashiness >>>> in this code to make it worthwhile to test >>> >>> We do have - that's how we found this case; it's part of test-hmp. >> >> The test-hmp runs by default with 0 MB of memory, the problem can only >> be found with some memory added to the machine. >> >> Perhaps we can simply update the test to add memory? > > Probably best to run it twice, 0MB and with say 2MB, as they're both > fairly magic values. OK, I'm going to update the test. Laurent
On Mon, 11 Sep 2017 14:10:14 +0200 Laurent Vivier <lvivier@redhat.com> wrote: > On 11/09/2017 14:04, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrange (berrange@redhat.com) wrote: > >> On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: > >>> However, if we start a qemu with no guest memory defined and then call > >>> dump-guest-memory without filtering, we get a core dump instead of a > >>> guest dump (s390x or x86_64, machine none). > >>> > >>> I can take a stab at fixing that, unless someone beats me to it. > >> > >> I wonder if someone wants to write a qtest job to run dump-guest-memory > >> across all machine types, on all targets. Seems we have enough crashiness > >> in this code to make it worthwhile to test > > > > We do have - that's how we found this case; it's part of test-hmp. > > The test-hmp runs by default with 0 MB of memory, the problem can only > be found with some memory added to the machine. > > Perhaps we can simply update the test to add memory? We have several combinations that can fail here... (cf. the problem with no memory and no filter above). > > BTW, I'm not sure it is really useful to dump memory of a machine > without CPU. Even so, it should not segfault (and neither should dumping a guest with no memory, even if it doesn't make sense).
On 11/09/2017 13:41, Cornelia Huck wrote: > On Mon, 11 Sep 2017 12:06:15 +0100 > "Daniel P. Berrange" <berrange@redhat.com> wrote: > >> On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: >>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) >>> fixes the problem for i386, do the same for ppc. >> >> What about all the other targets QEMU supports ? Have you checked if they >> are similarly affected, as we don't want to wait another 6 months to get a >> bug report that s390 or aarch64 crash in exactly the same way too. > > This patch actually prompted me to check s390, and the mentioned > command line works fine. > > However, if we start a qemu with no guest memory defined and then call > dump-guest-memory without filtering, we get a core dump instead of a > guest dump (s390x or x86_64, machine none). > > I can take a stab at fixing that, unless someone beats me to it. > I will update the test with this test case too. Thanks, Laurent
On 11.09.2017 13:00, Laurent Vivier wrote: > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > fixes the problem for i386, do the same for ppc. > > Running QEMU with > qemu-system-ppc64 -M none -nographic -m 256 > and executing > dump-guest-memory /dev/null 0 8192 > results in segfault > > Fix by checking if we have CPU. > > Signed-off-by: Laurent Vivier <lvivier@redhat.com> > --- > target/ppc/arch_dump.c | 17 +++++++++++------ > 1 file changed, 11 insertions(+), 6 deletions(-) > > diff --git a/target/ppc/arch_dump.c b/target/ppc/arch_dump.c > index 8e9397aa58..dcb7b19950 100644 > --- a/target/ppc/arch_dump.c > +++ b/target/ppc/arch_dump.c > @@ -224,17 +224,22 @@ typedef struct NoteFuncDescStruct NoteFuncDesc; > int cpu_get_dump_info(ArchDumpInfo *info, > const struct GuestPhysBlockList *guest_phys_blocks) > { > - PowerPCCPU *cpu = POWERPC_CPU(first_cpu); > - PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); > - > info->d_machine = PPC_ELF_MACHINE; > info->d_class = ELFCLASS; > > - if ((*pcc->interrupts_big_endian)(cpu)) { > - info->d_endian = ELFDATA2MSB; > + if (first_cpu) { > + PowerPCCPU *cpu = POWERPC_CPU(first_cpu); > + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); > + > + if ((*pcc->interrupts_big_endian)(cpu)) { > + info->d_endian = ELFDATA2MSB; > + } else { > + info->d_endian = ELFDATA2LSB; > + } > } else { > - info->d_endian = ELFDATA2LSB; > + info->d_endian = ELFDATA2MSB; > } > + > /* 64KB is the max page size for pseries kernel */ > if (strncmp(object_get_typename(qdev_get_machine()), > "pseries-", 8) == 0) { > Reviewed-by: Thomas Huth <thuth@redhat.com>
On 11.09.2017 14:15, Laurent Vivier wrote: > On 11/09/2017 14:13, Daniel P. Berrange wrote: >> On Mon, Sep 11, 2017 at 02:10:14PM +0200, Laurent Vivier wrote: >>> On 11/09/2017 14:04, Dr. David Alan Gilbert wrote: >>>> * Daniel P. Berrange (berrange@redhat.com) wrote: >>>>> On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote: >>>>>> On Mon, 11 Sep 2017 12:06:15 +0100 >>>>>> "Daniel P. Berrange" <berrange@redhat.com> wrote: >>>>>> >>>>>>> On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote: >>>>>>>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) >>>>>>>> fixes the problem for i386, do the same for ppc. >>>>>>> >>>>>>> What about all the other targets QEMU supports ? Have you checked if they >>>>>>> are similarly affected, as we don't want to wait another 6 months to get a >>>>>>> bug report that s390 or aarch64 crash in exactly the same way too. >>>>>> >>>>>> This patch actually prompted me to check s390, and the mentioned >>>>>> command line works fine. >>>>>> >>>>>> However, if we start a qemu with no guest memory defined and then call >>>>>> dump-guest-memory without filtering, we get a core dump instead of a >>>>>> guest dump (s390x or x86_64, machine none). >>>>>> >>>>>> I can take a stab at fixing that, unless someone beats me to it. >>>>> >>>>> I wonder if someone wants to write a qtest job to run dump-guest-memory >>>>> across all machine types, on all targets. Seems we have enough crashiness >>>>> in this code to make it worthwhile to test >>>> >>>> We do have - that's how we found this case; it's part of test-hmp. >>> >>> The test-hmp runs by default with 0 MB of memory, the problem can only >>> be found with some memory added to the machine. >>> >>> Perhaps we can simply update the test to add memory? >> >> Probably best to run it twice, 0MB and with say 2MB, as they're both >> fairly magic values. > > OK, I'm going to update the test. Thanks! But please note that it is only the "none" machine which is started without memory and CPU by default - all the other boards should have a default set of memory and at least one CPU. So we should only add an additional tests for the "none" machine here. Thomas
----- Original Message ----- > From: "Thomas Huth" <thuth@redhat.com> > To: "Laurent Vivier" <lvivier@redhat.com>, qemu-devel@nongnu.org > Cc: "David Gibson" <david@gibson.dropbear.id.au>, qemu-ppc@nongnu.org, "Dr . David Alan Gilbert" > <dgilbert@redhat.com>, "Miroslav Rezanina" <mrezanin@redhat.com> > Sent: Monday, September 11, 2017 4:36:01 PM > Subject: Re: [PATCH] hmp: fix "dump-quest-memory" segfault (ppc) > > On 11.09.2017 13:00, Laurent Vivier wrote: > > Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) > > fixes the problem for i386, do the same for ppc. > > > > Running QEMU with > > qemu-system-ppc64 -M none -nographic -m 256 > > and executing > > dump-guest-memory /dev/null 0 8192 > > results in segfault > > > > Fix by checking if we have CPU. > > > > Signed-off-by: Laurent Vivier <lvivier@redhat.com> > > --- > > target/ppc/arch_dump.c | 17 +++++++++++------ > > 1 file changed, 11 insertions(+), 6 deletions(-) > > > > diff --git a/target/ppc/arch_dump.c b/target/ppc/arch_dump.c > > index 8e9397aa58..dcb7b19950 100644 > > --- a/target/ppc/arch_dump.c > > +++ b/target/ppc/arch_dump.c > > @@ -224,17 +224,22 @@ typedef struct NoteFuncDescStruct NoteFuncDesc; > > int cpu_get_dump_info(ArchDumpInfo *info, > > const struct GuestPhysBlockList *guest_phys_blocks) > > { > > - PowerPCCPU *cpu = POWERPC_CPU(first_cpu); > > - PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); > > - > > info->d_machine = PPC_ELF_MACHINE; > > info->d_class = ELFCLASS; > > > > - if ((*pcc->interrupts_big_endian)(cpu)) { > > - info->d_endian = ELFDATA2MSB; > > + if (first_cpu) { > > + PowerPCCPU *cpu = POWERPC_CPU(first_cpu); > > + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); > > + > > + if ((*pcc->interrupts_big_endian)(cpu)) { > > + info->d_endian = ELFDATA2MSB; > > + } else { > > + info->d_endian = ELFDATA2LSB; > > + } > > } else { > > - info->d_endian = ELFDATA2LSB; > > + info->d_endian = ELFDATA2MSB; > > } > > + > > /* 64KB is the max page size for pseries kernel */ > > if (strncmp(object_get_typename(qdev_get_machine()), > > "pseries-", 8) == 0) { > > > > Reviewed-by: Thomas Huth <thuth@redhat.com> > We need similar fix for aarch64 too. Mirek
On 12.09.2017 06:52, Miroslav Rezanina wrote: > > > ----- Original Message ----- >> From: "Thomas Huth" <thuth@redhat.com> >> To: "Laurent Vivier" <lvivier@redhat.com>, qemu-devel@nongnu.org >> Cc: "David Gibson" <david@gibson.dropbear.id.au>, qemu-ppc@nongnu.org, "Dr . David Alan Gilbert" >> <dgilbert@redhat.com>, "Miroslav Rezanina" <mrezanin@redhat.com> >> Sent: Monday, September 11, 2017 4:36:01 PM >> Subject: Re: [PATCH] hmp: fix "dump-quest-memory" segfault (ppc) >> >> On 11.09.2017 13:00, Laurent Vivier wrote: >>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) >>> fixes the problem for i386, do the same for ppc. >>> >>> Running QEMU with >>> qemu-system-ppc64 -M none -nographic -m 256 >>> and executing >>> dump-guest-memory /dev/null 0 8192 >>> results in segfault >>> >>> Fix by checking if we have CPU. [...] > > We need similar fix for aarch64 too. Yes, Laurent already posted a v2 which includes a patch for ARM, too: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg02586.html Thomas
diff --git a/target/ppc/arch_dump.c b/target/ppc/arch_dump.c index 8e9397aa58..dcb7b19950 100644 --- a/target/ppc/arch_dump.c +++ b/target/ppc/arch_dump.c @@ -224,17 +224,22 @@ typedef struct NoteFuncDescStruct NoteFuncDesc; int cpu_get_dump_info(ArchDumpInfo *info, const struct GuestPhysBlockList *guest_phys_blocks) { - PowerPCCPU *cpu = POWERPC_CPU(first_cpu); - PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); - info->d_machine = PPC_ELF_MACHINE; info->d_class = ELFCLASS; - if ((*pcc->interrupts_big_endian)(cpu)) { - info->d_endian = ELFDATA2MSB; + if (first_cpu) { + PowerPCCPU *cpu = POWERPC_CPU(first_cpu); + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); + + if ((*pcc->interrupts_big_endian)(cpu)) { + info->d_endian = ELFDATA2MSB; + } else { + info->d_endian = ELFDATA2LSB; + } } else { - info->d_endian = ELFDATA2LSB; + info->d_endian = ELFDATA2MSB; } + /* 64KB is the max page size for pseries kernel */ if (strncmp(object_get_typename(qdev_get_machine()), "pseries-", 8) == 0) {
Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault) fixes the problem for i386, do the same for ppc. Running QEMU with qemu-system-ppc64 -M none -nographic -m 256 and executing dump-guest-memory /dev/null 0 8192 results in segfault Fix by checking if we have CPU. Signed-off-by: Laurent Vivier <lvivier@redhat.com> --- target/ppc/arch_dump.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)