[Qemu-commits] [qemu/qemu] 7386ae: ppc/spapr: Refactor h_client_architecture_support(...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 7386ae6372cc07c77a39cb3aa185848b43f7ae34
      
https://github.com/qemu/qemu/commit/7386ae6372cc07c77a39cb3aa185848b43f7ae34
  Author: Thomas Huth <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M hw/ppc/spapr_hcall.c

  Log Message:
  -----------
  ppc/spapr: Refactor h_client_architecture_support() CPU parsing code

The h_client_architecture_support() function has become quite big
and nested already. So factor out the code that takes care of the
sPAPR compatibility PVRs (which will be modified by the following
patches).

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


  Commit: 8cd2ce7aaa3c3fadc561f40045d4d53ff72e94ef
      
https://github.com/qemu/qemu/commit/8cd2ce7aaa3c3fadc561f40045d4d53ff72e94ef
  Author: Thomas Huth <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

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

  Log Message:
  -----------
  ppc: Split pcr_mask settings into supported bits and the register mask

The current pcr_mask values are ambiguous: Should these be the mask
that defines valid bits in the PCR register? Or should these rather
indicate which compatibility levels are possible? Anyway, POWER6 and
POWER7 should certainly not use the same values here. So let's
introduce an additional variable "pcr_supported" here which is
used to indicate the valid compatibility levels, and use pcr_mask
to signal the valid bits in the PCR register.

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


  Commit: 52b2519c4ea9a6aa4df7abfe35fd1755c5c8546c
      
https://github.com/qemu/qemu/commit/52b2519c4ea9a6aa4df7abfe35fd1755c5c8546c
  Author: Thomas Huth <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M target-ppc/kvm.c
    M target-ppc/kvm_ppc.h

  Log Message:
  -----------
  ppc: Provide function to get CPU class of the host CPU

When running with KVM, we might be interested in some details
of the host CPU class, too, so provide a function to get the
corresponding CPU class.

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


  Commit: eac4fba965136f61cc239a450bec12adcef6b449
      
https://github.com/qemu/qemu/commit/eac4fba965136f61cc239a450bec12adcef6b449
  Author: Thomas Huth <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

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

  Log Message:
  -----------
  ppc: Improve PCR bit selection in ppc_set_compat()

When using an olderr PowerISA level, all the upper compatibility
bits have to be enabled, too. For example when we want to run
something in PowerISA 2.05 compatibility mode on POWER8, the bit
for 2.06 has to be set beside the bit for 2.05.
Additionally, to make sure that we do not set bits that are not
supported by the host, we apply a mask with the known-to-be-good
bits here, too.

Signed-off-by: Thomas Huth <address@hidden>
[dwg: Added some #ifs to fix compile on 32-bit targets]
Signed-off-by: David Gibson <address@hidden>


  Commit: b30ff227c27c931155f768a04c44a6c8757f195f
      
https://github.com/qemu/qemu/commit/b30ff227c27c931155f768a04c44a6c8757f195f
  Author: Thomas Huth <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M hw/ppc/spapr_hcall.c
    M target-ppc/translate_init.c

  Log Message:
  -----------
  ppc: Add PowerISA 2.07 compatibility mode

Make sure that guests can use the PowerISA 2.07 CPU sPAPR
compatibility mode when they request it and the target CPU
supports it.

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


  Commit: 42bff4772ef96d901772240b10eda6d66ef771a1
      
https://github.com/qemu/qemu/commit/42bff4772ef96d901772240b10eda6d66ef771a1
  Author: Anton Blanchard <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M include/elf.h

  Log Message:
  -----------
  Add PowerPC AT_HWCAP2 definitions

We need the PPC_FEATURE2_HAS_HTM bit in a subsequent patch, so
add the PowerPC AT_HWCAP2 definitions.

Signed-off-by: Anton Blanchard <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: bc9ca5958d084222cdb233619dfc5046c81fb76d
      
https://github.com/qemu/qemu/commit/bc9ca5958d084222cdb233619dfc5046c81fb76d
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M hw/ide/macio.c
    M include/hw/ppc/mac_dbdma.h

  Log Message:
  -----------
  macio: call dma_memory_unmap() at the end of each DMA transfer

This ensures that the underlying memory is marked dirty once the transfer
is complete and resolves cache coherency problems under MacOS 9.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d0e5a8f2937de66778d94c20a8fc5cf43501fa04
      
https://github.com/qemu/qemu/commit/d0e5a8f2937de66778d94c20a8fc5cf43501fa04
  Author: Bharata B Rao <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Ensure all LMBs are represented in ibm,dynamic-memory

Memory hotplug can fail for some combinations of RAM and maxmem when
DDW is enabled in the presence of devices like nec-usb-xhci. DDW depends
on maximum addressable memory returned by guest and this value is currently
being calculated wrongly by the guest kernel routine memory_hotplug_max().
While there is an attempt to fix the guest kernel, this patch works
around the problem within QEMU itself.

memory_hotplug_max() routine in the guest kernel arrives at max
addressable memory by multiplying lmb-size with the lmb-count obtained
from ibm,dynamic-memory property. There are two assumptions here:

- All LMBs are part of ibm,dynamic memory: This is not true for PowerKVM
  where only hot-pluggable LMBs are present in this property.
- The memory area comprising of RAM and hotplug region is contiguous: This
  needn't be true always for PowerKVM as there can be gap between
  boot time RAM and hotplug region.

To work around this guest kernel bug, ensure that ibm,dynamic-memory
has information about all the LMBs (RMA, boot-time LMBs, future
hotpluggable LMBs, and dummy LMBs to cover the gap between RAM and
hotpluggable region).

RMA is represented separately by address@hidden node. Hence mark RMA LMBs
and also the LMBs for the gap b/n RAM and hotpluggable region as
reserved and as having no valid DRC so that these LMBs are not considered
by the guest.

Signed-off-by: Bharata B Rao <address@hidden>
Reviewed-by: Michael Roth <address@hidden>
Reviewed-by: Nathan Fontenot <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: a28aae041aa76a779df6467a7fe68b9e8a8b2c0a
      
https://github.com/qemu/qemu/commit/a28aae041aa76a779df6467a7fe68b9e8a8b2c0a
  Author: Peter Maydell <address@hidden>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
    M hw/ide/macio.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M include/elf.h
    M include/hw/ppc/mac_dbdma.h
    M include/hw/ppc/spapr.h
    M target-ppc/cpu-qom.h
    M target-ppc/cpu.h
    M target-ppc/kvm.c
    M target-ppc/kvm_ppc.h
    M target-ppc/translate_init.c

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

ppc patch queue for 2016-06-14

Latest patch queue for ppc.
    * Allow qemu to support a generic architecture 2.07 (POWER8-era)
      compatibility mode.  This is useful for guests which are POWER8
      aware, but don't know about the specific POWER8 variant that
      qemu (and/or KVM) is emulating. (Thomas Huth)
    * Fix a bug where macio wasn't removing DMA mappings (Mark Cave-Ayland)
    * Add a workaround for Linux guest's miscalculation of maximum
      memory address (including hotplugged memory), which could break
      when hotplug memory was combined with VFIO.  The previous
      approach was technically correct by spec, but differed from
      PowerVM's behaviour enough to trip a guest kernel bug.  This
      works around the bug, while remaining correct-to-spec. (Bharata Rao)

# gpg: Signature made Tue 14 Jun 2016 06:53:58 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-20160614:
  spapr: Ensure all LMBs are represented in ibm,dynamic-memory
  macio: call dma_memory_unmap() at the end of each DMA transfer
  Add PowerPC AT_HWCAP2 definitions
  ppc: Add PowerISA 2.07 compatibility mode
  ppc: Improve PCR bit selection in ppc_set_compat()
  ppc: Provide function to get CPU class of the host CPU
  ppc: Split pcr_mask settings into supported bits and the register mask
  ppc/spapr: Refactor h_client_architecture_support() CPU parsing code

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


Compare: https://github.com/qemu/qemu/compare/2c96c379ac7a...a28aae041aa7