[Qemu-commits] [qemu/qemu] d35aef: ppc/pnv: introduce a new intc_create() operation t...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d35aefa9ae150a8a5943ca3d9102020a5382de0b
      
https://github.com/qemu/qemu/commit/d35aefa9ae150a8a5943ca3d9102020a5382de0b
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/ppc/pnv.c
    M hw/ppc/pnv_core.c
    M include/hw/ppc/pnv.h

  Log Message:
  -----------
  ppc/pnv: introduce a new intc_create() operation to the chip model

On Power9, the thread interrupt presenter has a different type and is
linked to the chip owning the cores.

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


  Commit: 04026890f2d71afb36dbef24c370171cd0c42913
      
https://github.com/qemu/qemu/commit/04026890f2d71afb36dbef24c370171cd0c42913
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/ppc/pnv.c
    M hw/ppc/pnv_lpc.c
    M include/hw/ppc/pnv.h
    M include/hw/ppc/pnv_lpc.h

  Log Message:
  -----------
  ppc/pnv: introduce a new isa_create() operation to the chip model

This moves the details of the ISA bus creation under the LPC model but
more important, the new PnvChip operation will let us choose the chip
class to use when we introduce the different chip classes for Power9
and Power8. It hides away the processor chip controllers from the
machine.

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


  Commit: b94020268e0b6659499e250d25346baaa9888fed
      
https://github.com/qemu/qemu/commit/b94020268e0b6659499e250d25346baaa9888fed
  Author: Greg Kurz <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  spapr_cpu_core: migrate per-CPU data

A per-CPU machine data pointer was recently added to PowerPCCPU. The
motivation is to to hide platform specific details from the core CPU
code. This per-CPU data can hold state which is relevant to the guest
though, eg, Virtual Processor Areas, and we should migrate this state.

This patch adds the plumbing so that we can migrate the per-CPU data
for PAPR guests. We only do this for newer machine types for the sake
of backward compatibility. No state is migrated for the moment: the
vmstate_spapr_cpu_state structure will be populated by subsequent
patches.

Signed-off-by: Greg Kurz <address@hidden>
[dwg: Fix some trivial spelling and spacing errors]
Signed-off-by: David Gibson <address@hidden>


  Commit: 7f9fe3f02d9e796e8bcd37628e17127dec515991
      
https://github.com/qemu/qemu/commit/7f9fe3f02d9e796e8bcd37628e17127dec515991
  Author: Greg Kurz <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/ppc/spapr_cpu_core.c

  Log Message:
  -----------
  spapr_cpu_core: migrate VPA related state

QEMU implements the "Shared Processor LPAR" (SPLPAR) option, which allows
the hypervisor to time-slice a physical processor into multiple virtual
processor. The intent is to allow more guests to run, and to optimize
processor utilization.

The guest OS can cede idle VCPUs, so that their processing capacity may
be used by other VCPUs, with the H_CEDE hcall. The guest OS can also
optimize spinlocks, by confering the time-slice of a spinning VCPU to the
spinlock holder if it's currently notrunning, with the H_CONFER hcall.

Both hcalls depend on a "Virtual Processor Area" (VPA) to be registered
by the guest OS, generally during early boot. Other per-VCPU areas can
be registered: the "SLB Shadow Buffer" which allows a more efficient
dispatching of VCPUs, and the "Dispatch Trace Log Buffer" (DTL) which
is used to compute time stolen by the hypervisor. Both DTL and SLB Shadow
areas depend on the VPA to be registered.

The VPA/SLB Shadow/DTL are state that QEMU should migrate, but this doesn't
happen, for no apparent reason other than it was just never coded. This
causes the features listed above to stop working after migration, and it
breaks the logic of the H_REGISTER_VPA hcall in the destination.

The VPA is set at the guest request, ie, we don't have to migrate
it before the guest has actually set it. This patch hence adds an
"spapr_cpu/vpa" subsection to the recently introduced per-CPU machine
data migration stream.

Since DTL and SLB Shadow are optional and both depend on VPA, they get
their own subsections "spapr_cpu/vpa/slb_shadow" and "spapr_cpu/vpa/dtl"
hanging from the "spapr_cpu/vpa" subsection.

Note that this won't break migration to older QEMUs. Is is already handled
by only registering the vmstate handler for per-CPU data with newer machine
types.

Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 77864267c3c82a4938d628b9313bce8fcce6373d
      
https://github.com/qemu/qemu/commit/77864267c3c82a4938d628b9313bce8fcce6373d
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  ppc/pnv: introduce Pnv8Chip and Pnv9Chip models

It introduces a base PnvChip class from which the specific processor
chip classes, Pnv8Chip and Pnv9Chip, inherit. Each of them needs to
define an init and a realize routine which will create the controllers
of the target processor. For the moment, the base PnvChip class
handles the XSCOM bus and the cores.

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


  Commit: bb7ab95c96756663cf76914b171971d9582f828d
      
https://github.com/qemu/qemu/commit/bb7ab95c96756663cf76914b171971d9582f828d
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/ppc/pnv.c

  Log Message:
  -----------
  ppc/pnv: consolidate the creation of the ISA bus device tree

The device tree node of the ISA bus was being partially done in
different places. Move all the nodes creation under the same routine.

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


  Commit: ad99d04c76debb0d60c0bbb5d4f6ebb3509ddc91
      
https://github.com/qemu/qemu/commit/ad99d04c76debb0d60c0bbb5d4f6ebb3509ddc91
  Author: David Gibson <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M target/ppc/compat.c
    M target/ppc/cpu.h

  Log Message:
  -----------
  target/ppc: Allow cpu compatiblity checks based on type, not instance

ppc_check_compat() is used in a number of places to check if a cpu object
supports a certain compatiblity mode, subject to various constraints.

It takes a PowerPCCPU *, however it really only depends on the cpu's class.
We have upcoming cases where it would be useful to make compatibility
checks before we fully instantiate the cpu objects.

ppc_type_check_compat() will now make an equivalent check, but based on a
CPU's QOM typename instead of an instantiated CPU object.

We make use of the new interface in several places in spapr, where we're
essentially making a global check, rather than one specific to a particular
cpu.  This avoids some ugly uses of first_cpu to grab a "representative"
instance.

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


  Commit: 9f6edd066e92f61543ea561b7c3cb340f30a7017
      
https://github.com/qemu/qemu/commit/9f6edd066e92f61543ea561b7c3cb340f30a7017
  Author: David Gibson <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  spapr: Compute effective capability values earlier

Previously, the effective values of the various spapr capability flags
were only determined at machine reset time.  That was a lazy way of making
sure it was after cpu initialization so it could use the cpu object to
inform the defaults.

But we've now improved the compat checking code so that we don't need to
instantiate the cpus to use it.  That lets us move the resolution of the
capability defaults much earlier.

This is going to be necessary for some future capabilities.

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


  Commit: e2e4f64118d128c41bd3c787afd2b9822ab758cd
      
https://github.com/qemu/qemu/commit/e2e4f64118d128c41bd3c787afd2b9822ab758cd
  Author: David Gibson <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  spapr: Add cpu_apply hook to capabilities

spapr capabilities have an apply hook to actually activate (or deactivate)
the feature in the system at reset time.  However, a number of capabilities
affect the setup of cpus, and need to be applied to each of them -
including hotplugged cpus for extra complication.  To make this simpler,
add an optional cpu_apply hook that is called from spapr_cpu_reset().

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


  Commit: 24c6863c7b61efcfe4a0f0916ed4e8b797c8d281
      
https://github.com/qemu/qemu/commit/24c6863c7b61efcfe4a0f0916ed4e8b797c8d281
  Author: David Gibson <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  target/ppc: Add kvmppc_hpt_needs_host_contiguous_pages() helper

KVM HV has a restriction that for HPT mode guests, guest pages must be hpa
contiguous as well as gpa contiguous.  We have to account for that in
various places.  We determine whether we're subject to this restriction
from the SMMU information exposed by KVM.

Planned cleanups to the way we handle this will require knowing whether
this restriction is in play in wider parts of the code.  So, expose a
helper function which returns it.

This does mean some redundant calls to kvm_get_smmu_info(), but they'll go
away again with future cleanups.

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


  Commit: 4fe75a8ccd8005f8d0322c5b85ebee6243b2e753
      
https://github.com/qemu/qemu/commit/4fe75a8ccd8005f8d0322c5b85ebee6243b2e753
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  spapr: split the IRQ allocation sequence

Today, when a device requests for IRQ number in a sPAPR machine, the
spapr_irq_alloc() routine first scans the ICSState status array to
find an empty slot and then performs the assignement of the selected
numbers. Split this sequence in two distinct routines : spapr_irq_find()
for lookups and spapr_irq_claim() for claiming the IRQ numbers.

This will ease the introduction of a static layout of IRQ numbers.

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


  Commit: 71b5c8d26e35549db4b83d907b2886623d8dd99a
      
https://github.com/qemu/qemu/commit/71b5c8d26e35549db4b83d907b2886623d8dd99a
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

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

  Log Message:
  -----------
  spapr: remove unused spapr_irq routines

spapr_irq_alloc_block and spapr_irq_alloc() are now deprecated.

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


  Commit: 88d8d5555d0257a31b5891a328d957cc9b579eb2
      
https://github.com/qemu/qemu/commit/88d8d5555d0257a31b5891a328d957cc9b579eb2
  Author: John Arbuckle <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M target/ppc/fpu_helper.c

  Log Message:
  -----------
  fpu_helper.c: fix helper_fpscr_clrbit() function

Fix the helper_fpscr_clrbit() function so it correctly sets the FEX
and VX bits.

Determining the value for the Floating Point Status and Control
Register's (FPSCR) FEX bit is suppose to be done like this:

FEX = (VX & VE) | (OX & OE) | (UX & UE) | (ZX & ZE) | (XX & XE))

It is described as "the logical OR of all the floating-point exception
bits masked by their respective enable bits". It was not implemented
correctly. The value of FEX would stay on even when all other bits
were set to off.

The VX bit is described as "the logical OR of all of the invalid
operation exceptions". This bit was also not implemented correctly. It
too would stay on when all the other bits were set to off.

My main source of information is an IBM document called:

PowerPC Microprocessor Family:
The Programming Environments for 32-Bit Microprocessors

Page 62 is where the FPSCR information is located.

This is an older copy than the one I use but it is still very useful:
https://www.pdfdrive.net/powerpc-microprocessor-family-the-programming-environments-for-32-e3087633.html

I use a G3 and G5 iMac to compare bit values with QEMU. This patch
fixed all the problems I was having with these bits.

Signed-off-by: John Arbuckle <address@hidden>
[dwg: Re-wrapped commit message]
Signed-off-by: David Gibson <address@hidden>


  Commit: a69232e2a36b9fcee46ddbf140ab2de1583abf39
      
https://github.com/qemu/qemu/commit/a69232e2a36b9fcee46ddbf140ab2de1583abf39
  Author: Sebastian Bauer <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/display/sm501.c

  Log Message:
  -----------
  sm501: Fix hardware cursor color conversion

According to the sm501 specs the hardware cursor colors are to be given in
the rgb565 format, but the code currently interprets them as bgr565.

Therefore, the colors of the hardware cursors are wrong in the QEMU
display, e.g., the standard mouse pointer of AmigaOS appears blue instead
of red. This change fixes this issue by replacing the existing naive
bgr565 => rgb888 conversion with a standard rgb565 => rgb888 one that also
scales the color component values properly.

Signed-off-by: Sebastian Bauer <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 39aeba6caa4b9de8b195fddddae5cc5835d19b04
      
https://github.com/qemu/qemu/commit/39aeba6caa4b9de8b195fddddae5cc5835d19b04
  Author: BALATON Zoltan <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M hw/i2c/ppc4xx_i2c.c
    M include/hw/i2c/ppc4xx_i2c.h

  Log Message:
  -----------
  ppc4xx_i2c: Remove unimplemented sdata and intr registers

We don't emulate slave mode so related registers are not needed.
[lh]sadr are only retained to avoid too many warnings and simplify
debugging but sdata is not even correct because device has a 4 byte
FIFO instead so just remove this unimplemented register for now.

The intr register is also not implemented correctly, it is for
diagnostics and normally not even visible on device without explicitly
enabling it. As no guests are known to need this remove it as well.

Signed-off-by: BALATON Zoltan <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: ef9173a5c086b5114343a86943f9b26a9c72d7d6
      
https://github.com/qemu/qemu/commit/ef9173a5c086b5114343a86943f9b26a9c72d7d6
  Author: BALATON Zoltan <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M default-configs/ppc-softmmu.mak
    M default-configs/ppcemb-softmmu.mak
    M hw/i2c/ppc4xx_i2c.c
    M include/hw/i2c/ppc4xx_i2c.h

  Log Message:
  -----------
  ppc4xx_i2c: Implement directcntl register

As well as being able to generate its own i2c transactions, the ppc4xx
i2c controller has a DIRECTCNTL register which allows explicit control
of the i2c lines.

Using this register an OS can directly bitbang i2c operations. In
order to let emulated i2c devices respond to this, we need to wire up
the DIRECTCNTL register to qemu's bitbanged i2c handling code.

Signed-off-by: BALATON Zoltan <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0c8d8c8b8fd6db3110a5be3886b1ed9ba89be8b1
      
https://github.com/qemu/qemu/commit/0c8d8c8b8fd6db3110a5be3886b1ed9ba89be8b1
  Author: BALATON Zoltan <address@hidden>
  Date:   2018-06-21 (Thu, 21 Jun 2018)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Add missing opcode for icbt on PPC440

According to PPC440 User Manual PPC440 has multiple opcodes for icbt
instruction: one for compatibility with older cores and two 440
specific opcodes one of which is defined in BookE. QEMU only
implements two of these, add the missing one.

Signed-off-by: BALATON Zoltan <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d21bbcc655b4f611f3d9246d50dba0b6a404d784
      
https://github.com/qemu/qemu/commit/d21bbcc655b4f611f3d9246d50dba0b6a404d784
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

  Changed paths:
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF

  Log Message:
  -----------
  pseries: Update SLOF firmware image to qemu-slof-20180621

The changes are:
1. fixed broken_sc1;
2. added switching between boot consoles;
3. added PXE boot.

The full list is:
 > lib/libnet/pxelinux: Fix two off-by-one bugs in the pxelinux.cfg parser
 > lib/libnet/pxelinux: Make the size handling for pxelinux_load_cfg more 
 > logical
 > libc: Add a simple implementation of an assert() function
 > libnet: Support UUID-based pxelinux.cfg file names
 > slof: Add a helper function to get the contents of a property in C code
 > libnet: Add support for DHCPv4 options 209 and 210
 > libnet: Wire up pxelinux.cfg network booting
 > libnet: Add functions for downloading and parsing pxelinux.cfg files
 > libnet: Put code for determing TFTP error strings into a separate function
 > libc: Add the snprintf() function
 > libnet: Pass ip_version via struct filename_ip
 > resolve ihandle and xt handle in the input command (like for the output)
 > Fix output word
 > obp-tftp: Make sure to not overwrite paflof in memory
 > libnet: Get rid of unused huge_load and block_size parameters
 > libc: Check for NULL pointers in free()
 > libc: Implement strrchr()
 > libnet: Get rid of unnecessary (char *) casts
 > broken_sc1: check for H_PRIVILEGE
 > OF: Use new property "stdout-path" for boot console

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 2309832afdaf8d6451ebc2e81bace8eb8ea41293
      
https://github.com/qemu/qemu/commit/2309832afdaf8d6451ebc2e81bace8eb8ea41293
  Author: David Gibson <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

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

  Log Message:
  -----------
  spapr: Maximum (HPT) pagesize property

The way the POWER Hash Page Table (HPT) MMU is virtualized by KVM HV means
that every page that the guest puts in the pagetables must be truly
physically contiguous, not just GPA-contiguous.  In effect this means that
an HPT guest can't use any pagesizes greater than the host page size used
to back its memory.

At present we handle this by changing what we advertise to the guest based
on the backing pagesizes.  This is pretty bad, because it means the guest
sees a different environment depending on what should be host configuration
details.

As a start on fixing this, we add a new capability parameter to the
pseries machine type which gives the maximum allowed pagesizes for an
HPT guest.  For now we just create and validate the parameter without
making it do anything.

For backwards compatibility, on older machine types we set it to the max
available page size for the host.  For the 3.0 machine type, we fix it to
16, the intention being to only allow HPT pagesizes up to 64kiB by default
in future.

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


  Commit: 123eec655287e43e0e86154e8093a394aefa3958
      
https://github.com/qemu/qemu/commit/123eec655287e43e0e86154e8093a394aefa3958
  Author: David Gibson <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h

  Log Message:
  -----------
  spapr: Use maximum page size capability to simplify memory backend checking

The way we used to handle KVM allowable guest pagesizes for PAPR guests
required some convoluted checking of memory attached to the guest.

The allowable pagesizes advertised to the guest cpus depended on the memory
which was attached at boot, but then we needed to ensure that any memory
later hotplugged didn't change which pagesizes were allowed.

Now that we have an explicit machine option to control the allowable
maximum pagesize we can simplify this.  We just check all memory backends
against that declared pagesize.  We check base and cold-plugged memory at
reset time, and hotplugged memory at pre_plug() time.

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


  Commit: 27f00f0a108484a975dc075086f8461ff279e1b3
      
https://github.com/qemu/qemu/commit/27f00f0a108484a975dc075086f8461ff279e1b3
  Author: David Gibson <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

  Changed paths:
    M target/ppc/mmu-hash64.c
    M target/ppc/mmu-hash64.h

  Log Message:
  -----------
  target/ppc: Add ppc_hash64_filter_pagesizes()

The paravirtualized PAPR platform sometimes needs to restrict the guest to
using only some of the page sizes actually supported by the host's MMU.
At the moment this is handled in KVM specific code, but for consistency we
want to apply the same limitations to all accelerators.

This makes a start on this by providing a helper function in the cpu code
to allow platform code to remove some of the cpu's page size definitions
via a caller supplied callback.

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


  Commit: 9dceda5fc34a5868012260ee7271c7a6f36cc1f4
      
https://github.com/qemu/qemu/commit/9dceda5fc34a5868012260ee7271c7a6f36cc1f4
  Author: David Gibson <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

  Changed paths:
    M hw/ppc/spapr_caps.c

  Log Message:
  -----------
  spapr: Limit available pagesizes to provide a consistent guest environment

KVM HV has some limitations (deriving from the hardware) that mean not all
host-cpu supported pagesizes may be usable in the guest.  At present this
means that KVM guests and TCG guests may see different available page sizes
even if they notionally have the same vcpu model.  This is confusing and
also prevents migration between TCG and KVM.

This patch makes the environment consistent by always allowing the same set
of pagesizes.  Since we can't remove the KVM limitations, we do this by
always applying the same limitations it has, even to TCG guests.

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


  Commit: e5ca28ecab5c69b7578e22391a66c97c3979ffd8
      
https://github.com/qemu/qemu/commit/e5ca28ecab5c69b7578e22391a66c97c3979ffd8
  Author: David Gibson <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

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

  Log Message:
  -----------
  spapr: Don't rewrite mmu capabilities in KVM mode

Currently during KVM initialization on POWER, kvm_fixup_page_sizes()
rewrites a bunch of information in the cpu state to reflect the
capabilities of the host MMU and KVM.  This overwrites the information
that's already there reflecting how the TCG implementation of the MMU will
operate.

This means that we can get guest-visibly different behaviour between KVM
and TCG (and between different KVM implementations).  That's bad.  It also
prevents migration between KVM and TCG.

The pseries machine type now has filtering of the pagesizes it allows the
guest to use which means it can present a consistent model of the MMU
across all accelerators.

So, we can now replace kvm_fixup_page_sizes() with kvm_check_mmu() which
merely verifies that the expected cpu model can be faithfully handled by
KVM, rather than updating the cpu model to match KVM.

We call kvm_check_mmu() from the spapr cpu reset code.  This is a hack:
conceptually it makes more sense where fixup_page_sizes() was - in the KVM
cpu init path.  However, doing that would require moving the platform's
pagesize filtering much earlier, which would require a lot of work making
further adjustments.  There wouldn't be a lot of concrete point to doing
that, since the only KVM implementation which has the awkward MMU
restrictions is KVM HV, which can only work with an spapr guest anyway.

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


  Commit: c52e53f429aa562539f5da2e7c21c66c6f9a8a16
      
https://github.com/qemu/qemu/commit/c52e53f429aa562539f5da2e7c21c66c6f9a8a16
  Author: Peter Maydell <address@hidden>
  Date:   2018-06-22 (Fri, 22 Jun 2018)

  Changed paths:
    M default-configs/ppc-softmmu.mak
    M default-configs/ppcemb-softmmu.mak
    M hw/display/sm501.c
    M hw/i2c/ppc4xx_i2c.c
    M hw/ppc/pnv.c
    M hw/ppc/pnv_core.c
    M hw/ppc/pnv_lpc.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_vio.c
    M include/hw/i2c/ppc4xx_i2c.h
    M include/hw/ppc/pnv.h
    M include/hw/ppc/pnv_lpc.h
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_cpu_core.h
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF
    M target/ppc/compat.c
    M target/ppc/cpu.h
    M target/ppc/fpu_helper.c
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h
    M target/ppc/mmu-hash64.c
    M target/ppc/mmu-hash64.h
    M target/ppc/translate.c

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

ppc patch queue 2018-06-22

Another assorted patch of patches for ppc and spapr.
    * Rework of guest pagesize handling for ppc, which avoids guest
      visibly different behaviour between accelerators
    * A number of Pnv cleanups, working towards more complete POWER9
      support
    * Migration of VPA data, a significant bugfix

# gpg: Signature made Fri 22 Jun 2018 05:23:16 BST
# gpg:                using RSA key 6C38CACA20D9B392
# 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:                 aka "David Gibson (kernel.org) <address@hidden>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-3.0-20180622: (23 commits)
  spapr: Don't rewrite mmu capabilities in KVM mode
  spapr: Limit available pagesizes to provide a consistent guest environment
  target/ppc: Add ppc_hash64_filter_pagesizes()
  spapr: Use maximum page size capability to simplify memory backend checking
  spapr: Maximum (HPT) pagesize property
  pseries: Update SLOF firmware image to qemu-slof-20180621
  target/ppc: Add missing opcode for icbt on PPC440
  ppc4xx_i2c: Implement directcntl register
  ppc4xx_i2c: Remove unimplemented sdata and intr registers
  sm501: Fix hardware cursor color conversion
  fpu_helper.c: fix helper_fpscr_clrbit() function
  spapr: remove unused spapr_irq routines
  spapr: split the IRQ allocation sequence
  target/ppc: Add kvmppc_hpt_needs_host_contiguous_pages() helper
  spapr: Add cpu_apply hook to capabilities
  spapr: Compute effective capability values earlier
  target/ppc: Allow cpu compatiblity checks based on type, not instance
  ppc/pnv: consolidate the creation of the ISA bus device tree
  ppc/pnv: introduce Pnv8Chip and Pnv9Chip models
  spapr_cpu_core: migrate VPA related state
  ...

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


Compare: https://github.com/qemu/qemu/compare/45eb6fb6cea2...c52e53f429aa
      **NOTE:** This service been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.