qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 760d88: ppc64: fix compressed dump with pseri


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 760d88: ppc64: fix compressed dump with pseries kernel
Date: Wed, 10 Aug 2016 08:00:05 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 760d88d1d0c409f1afe6f1c91539487413e8b2a9
      
https://github.com/qemu/qemu/commit/760d88d1d0c409f1afe6f1c91539487413e8b2a9
  Author: Laurent Vivier <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M target-ppc/arch_dump.c

  Log Message:
  -----------
  ppc64: fix compressed dump with pseries kernel

If we don't provide the page size in target-ppc:cpu_get_dump_info(),
the default one (TARGET_PAGE_SIZE, 4KB) is used to create
the compressed dump. It works fine with Macintosh, but not with
pseries as the kernel default page size is 64KB.

Without this patch, if we generate a compressed dump in the QEMU monitor:

    (qemu) dump-guest-memory -z qemu.dump

This dump cannot be read by crash:

    # crash vmlinux qemu.dump
    ...
    WARNING: cannot translate vmemmap kernel virtual addresses:
       commands requiring page structure contents will fail
    ...

Page_size is used to determine the dumpfile's block size. The
block size needs to be at least the page size, but a multiple of page
size works fine too. For PPC64, linux supports either 4KB or 64KB software
page size. So we define the page_size to 64KB.

Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Andrew Jones <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: caebf37859b991c27ada22d5d7bfd929844bd20f
      
https://github.com/qemu/qemu/commit/caebf37859b991c27ada22d5d7bfd929844bd20f
  Author: Cédric Le Goater <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: remove extra type variable

The sPAPR CPU core typename is already available in the upper
block. Let's use it and move the check upward also.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: caf6316de90301e07444de95bd540c93ce9d333a
      
https://github.com/qemu/qemu/commit/caf6316de90301e07444de95bd540c93ce9d333a
  Author: Thomas Huth <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M target-ppc/cpu.h
    M target-ppc/translate_init.c

  Log Message:
  -----------
  ppc: Introduce a function to look up CPU alias strings

We will need this function to look up the aliases in the
spapr-cpu-core code, too.

Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 4babfaf05d020eab7d6469d12ce77cc142d22276
      
https://github.com/qemu/qemu/commit/4babfaf05d020eab7d6469d12ce77cc142d22276
  Author: Thomas Huth <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c

  Log Message:
  -----------
  hw/ppc/spapr: Look up CPU alias names instead of hard-coding the aliases

Hard-coding the CPU alias names in the spapr_cores[] array has
two big disadvantages:

1) We register a real type with the CPU alias name in
   spapr_cpu_core_register_types() - this prevents us from registering
   a CPU family name in kvm_ppc_register_host_cpu_type() with the same
   name (as we do it for the non-hotpluggable CPU types).

2) It's quite cumbersome to maintain the aliases here in sync with the
   ppc_cpu_aliases list from target-ppc/cpu-models.c.

So let's simply add proper alias lookup to the spapr cpu core code,
too (by checking whether the given model can be used directly, and
if not by trying to look up the given model as an alias name instead).

Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 9c83fc2e8e1630e4d0fb10055563844b6e2cf2e0
      
https://github.com/qemu/qemu/commit/9c83fc2e8e1630e4d0fb10055563844b6e2cf2e0
  Author: Thomas Huth <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M target-ppc/kvm.c

  Log Message:
  -----------
  ppc/kvm: Do not mess up the generic CPU family registration

The code for registering the sPAPR CPU host core type has been
added inbetween the generic CPU host core type and the generic
CPU family type. That way the instance_init and the class_init
information got lost when registering the generic CPU family
type. Fix it by moving the generic family registration before
the spapr cpu core registration code.

Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d11b268e1765e8878c1150d463b9f6dc3a8d4456
      
https://github.com/qemu/qemu/commit/d11b268e1765e8878c1150d463b9f6dc3a8d4456
  Author: Thomas Huth <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M target-ppc/kvm.c

  Log Message:
  -----------
  ppc/kvm: Register also a generic spapr CPU core family type

There is a regression with the "-cpu" parameter introduced by
the spapr CPU hotplug code: We used to allow to specify a
"CPU family" name with the "-cpu" parameter when running on KVM so
that the user does not need to know the gory details of the exact
CPU version of the host CPU. For example, it was possible to
use "-cpu POWER8" on a POWER8E host CPU. This behavior does not
work anymore with the new hot-pluggable spapr-cpu-core types.
Since libvirt already heavily depends on the old behavior, this
is quite a severe regression in the QEMU parameter interface.
Let's fix it by supporting a CPU family type for the spapr-cpu-core
on KVM, too.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1363812
Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d578cca333168ada7f9421beb3f07abe8990e7e3
      
https://github.com/qemu/qemu/commit/d578cca333168ada7f9421beb3f07abe8990e7e3
  Author: Peter Maydell <address@hidden>
  Date:   2016-08-10 (Wed, 10 Aug 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c
    M target-ppc/arch_dump.c
    M target-ppc/cpu.h
    M target-ppc/kvm.c
    M target-ppc/translate_init.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.7-20160810' into 
staging

ppc patch queue for 2016-08-10

Here are some more last minute PAPR and ppc related fixes for
qemu-2.7.  One patch makes compressed memory dumps work with guest
kernels using page sizes up to 64KiB.  This is important since most
current pseries guests use a 64KiB default page size.  The remainder
fix a regression with handling of CPU aliases which causes serious
problem for libvirt.

# gpg: Signature made Wed 10 Aug 2016 06:44:27 BST
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>"
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.7-20160810:
  ppc/kvm: Register also a generic spapr CPU core family type
  ppc/kvm: Do not mess up the generic CPU family registration
  hw/ppc/spapr: Look up CPU alias names instead of hard-coding the aliases
  ppc: Introduce a function to look up CPU alias strings
  spapr: remove extra type variable
  ppc64: fix compressed dump with pseries kernel

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/2bb15bddf260...d578cca33316

reply via email to

[Prev in Thread] Current Thread [Next in Thread]