Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: ef0d74212ab5101565313f172b8a5baafe9cd0d2
https://github.com/qemu/qemu/commit/ef0d74212ab5101565313f172b8a5baafe9cd0d2
Author: Cédric Le Goater <c...@kaod.org>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M target/ppc/mmu-hash64.h
Log Message:
-----------
target/ppc: return a nil HPT base address on sPAPR machines
commit e57ca75ce3b2 ("target/ppc: Manage external HPT via virtual
hypervisor") exported a set of methods to manipulate the HPT from the
core hash MMU. But SPR_SDR1 is still used under some circumstances to
get the base address of the HPT, which is incorrect for the sPAPR
machines.
Only the logging should be impacted.
Signed-off-by: Cédric Le Goater <c...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: 4a7518e0fdaa20525730ae0709a4afa0960a6c67
https://github.com/qemu/qemu/commit/4a7518e0fdaa20525730ae0709a4afa0960a6c67
Author: Cédric Le Goater <c...@kaod.org>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M target/ppc/cpu.h
M target/ppc/helper.h
M target/ppc/misc_helper.c
M target/ppc/mmu-book3s-v3.h
M target/ppc/mmu_helper.c
M target/ppc/translate.c
M target/ppc/translate_init.c
Log Message:
-----------
target/ppc: add basic support for PTCR on POWER9
The Partition Table Control Register (PTCR) is a hypervisor privileged
SPR. It contains the host real address of the Partition Table and its
size.
Signed-off-by: Cédric Le Goater <c...@kaod.org>
Reviewed-by: David Gibson <da...@gibson.dropbear.id.au>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: 090052aa08dbc774e55bc71a3058f24c8959586d
https://github.com/qemu/qemu/commit/090052aa08dbc774e55bc71a3058f24c8959586d
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr.c
M target/ppc/kvm.c
M target/ppc/kvm_ppc.h
Log Message:
-----------
spapr: Remove support for explicitly allocated RMAs
Current POWER cpus allow for a VRMA, a special mapping which describes a
guest's view of memory when in real mode (MMU off, from the guest's point
of view). Older cpus didn't have that which meant that to support a guest
a special host-contiguous region of memory was needed to give the guest its
Real Mode Area (RMA).
KVM used to provide special calls to allocate a contiguous RMA for those
cases. This was useful in the early days of KVM on Power to allow it to be
tested on PowerPC 970 chips as used in Macintosh G5 machines. Now, those
machines are so old as to be almost irrelevant.
The normal qemu deprecation process would require this to be marked
deprecated then removed in 2 releases. However, this can only be used
with corresponding support in the host kernel - which was dropped
years ago (in c17b98cf "KVM: PPC: Book3S HV: Remove code for PPC970
processors" of 2014-12-03 to be precise). Therefore it should be ok
to drop this immediately.
Just to be clear this only affects *KVM HV* guests with PowerPC 970,
and those already require an ancient host kernel. TCG and KVM PR
guests with PowerPC 970 should still work.
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Acked-by: Thomas Huth <th...@redhat.com>
Commit: 5ad553154d1137fbee9ec92b991e52123fa9bcd8
https://github.com/qemu/qemu/commit/5ad553154d1137fbee9ec92b991e52123fa9bcd8
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M target/ppc/mmu-hash64.c
M target/ppc/mmu-hash64.h
M target/ppc/translate_init.c
Log Message:
-----------
target/ppc: Add ppc_store_lpcr() helper
There are some fields in the cpu state which need to be updated when the
LPCR register is changed, which is done by ppc_hash64_update_rmls() and
ppc_hash64_update_vrma(). Code which alters env->spr[SPR_LPCR] needs to
call them afterwards to make sure the state is up to date.
That's easy to get wrong. The normal way of dealing with sitautions like
that is to use a helper which both updates the basic register value and the
derived state.
So, do that.
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Reviewed-by: Greg Kurz <gr...@kaod.org>
Commit: cf116ad4703a37b66122d97f139afb2321b9c40e
https://github.com/qemu/qemu/commit/cf116ad4703a37b66122d97f139afb2321b9c40e
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr_rtas.c
Log Message:
-----------
spapr: Clean up rtas_start_cpu() & rtas_stop_self()
This makes several minor cleanups to these functions:
* Follow usual convention of an early exit on error, rather than having
most of the body in an if
* Clearer naming of cpu and cpu_. Now callcpu is the cpu from which the
RTAS call is invoked, newcpu is the cpu which we're starting
* Use cpu_synchronize_state() instead of kvm_cpu_synchronize_state()
directly
* Remove pointless comment describing what cpu_synchronize_state() does
* Use ppc_store_lpcr() instead of directly writing the register field
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Reviewed-by: Greg Kurz <gr...@kaod.org>
Commit: 982489180b72a41f008bbcf761ba1ed3f5f916ba
https://github.com/qemu/qemu/commit/982489180b72a41f008bbcf761ba1ed3f5f916ba
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr_rtas.c
Log Message:
-----------
spapr: Remove unhelpful helpers from rtas_start_cpu()
rtas_start_cpu() calls spapr_cpu_update_tb_offset() and
spapr_cpu_set_endianness() to initialize certain things in the new cpu's
state. This is the only caller of those helpers, and they're each only
a few lines long, so we might as well just fold them into the caller.
In addition, those helpers initialize state on the new cpu to match that of
the first cpu. That will generally work, but might be at least logically
incorrect if the first cpu has been set offline by the guest. So, instead
base the state on that of the cpu invoking the RTAS call, which is
obviously active already.
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Reviewed-by: Greg Kurz <gr...@kaod.org>
Commit: 84369f639ec0ae08b5238f9abe383e8cd4998e98
https://github.com/qemu/qemu/commit/84369f639ec0ae08b5238f9abe383e8cd4998e98
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr.c
M hw/ppc/spapr_cpu_core.c
M hw/ppc/spapr_rtas.c
M include/hw/ppc/spapr_cpu_core.h
Log Message:
-----------
spapr: Make a helper to set up cpu entry point state
Under PAPR, only the boot CPU is active when the system starts. Other cpus
must be explicitly activated using an RTAS call. The entry state for the
boot and secondary cpus isn't identical, but it has some things in common.
We're going to add a bit more common setup later, too, so to simplify
make a helper which sets up the common entry state for both boot and
secondary cpu threads.
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Signed-off-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Reviewed-by: Greg Kurz <gr...@kaod.org>
Commit: 295b6c26aca97c5f6f6609f62d958af6af848454
https://github.com/qemu/qemu/commit/295b6c26aca97c5f6f6609f62d958af6af848454
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr_hcall.c
Log Message:
-----------
spapr: Clean up LPCR updates from hypercalls
There are several places in spapr_hcall.c where we need to update the LPCR
value on all CPUs. We do this with the set_spr() helper. That's not
really correct because this directly sets the SPR value, without going
through the ppc_store_lpcr() helper which may need to update state based
on the LPCR change.
In fact, set_spr() is only ever used for the LPCR, so replace it with an
explicit LPCR updated which uses the right low-level helper. While we're
there, move the CPU_FOREACH() which was in every one of the callers into
the new helper: set_all_lpcrs().
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Commit: f00bed9521cee4d67c4937b51de692e0bcf9efef
https://github.com/qemu/qemu/commit/f00bed9521cee4d67c4937b51de692e0bcf9efef
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr_rtas.c
M target/ppc/translate_init.c
Log Message:
-----------
target/ppc: Delay initialization of LPCR_UPRT for secondary cpus
In cpu_ppc_set_papr() the UPRT and GTSE bits of the LPCR default value are
initialized based on on ppc64_radix_guest(). Which seems reasonable,
except that ppc64_radix_guest() is based on spapr->patb_entry which is
only set up in spapr_machine_reset, called _after_ cpu_ppc_set_papr() for
boot cpus. Well, and the fact that modifying the SPR default value for an
instance rather than a class is kind of yucky.
The initialization here is really only necessary or valid for
hotplugged cpus; the base cpu initialization already sets a value
that's good enough for the boot cpus until the guest uses an hcall to
configure it's preferred MMU mode.
So, move this initialization to the rtas_start_cpu() path, at which point
ppc64_radix_guest() will have a sensible value, to make sure secondary cpus
come up in an MMU mode matching the existing cpus.
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Commit: da20aed12a983dcaa6ccef80c0175f438e2780e7
https://github.com/qemu/qemu/commit/da20aed12a983dcaa6ccef80c0175f438e2780e7
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr_cpu_core.c
M target/ppc/cpu.h
M target/ppc/kvm.c
M target/ppc/translate_init.c
Log Message:
-----------
spapr: Move PAPR mode cpu setup fully to spapr code
cpu_ppc_set_papr() does several things:
1) it sets up the virtual hypervisor interface
2) it prevents the cpu from ever entering hypervisor mode
3) it tells KVM that we're emulating a cpu in PAPR mode
and 4) it configures the LPCR and AMOR (hypervisor privileged registers)
so that TCG will behave correctly for PAPR guests, without
attempting to emulate the cpu in hypervisor mode
(1) & (2) make sense for any virtual hypervisor (if another one ever
exists).
(3) belongs more properly in the machine type specific to a PAPR guest, so
move it to spapr_cpu_init(). While we're at it, remove an ugly test on
kvm_enabled() by making kvmppc_set_papr() a safe no-op on non-KVM.
(4) also belongs more properly in the machine type specific code. (4) is
done by mangling the default values of the SPRs, so that they will be set
correctly at reset time. Manipulating usually-static parameters of the cpu
model like this is kind of ugly, especially since the values used really
have more to do with the platform than the cpu.
The spapr code already has places for PAPR specific initializations of
register state in spapr_cpu_reset(), so move this handling there.
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Commit: 47a9b5515475d91cb70791fe55182cf2fead135d
https://github.com/qemu/qemu/commit/47a9b5515475d91cb70791fe55182cf2fead135d
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr_cpu_core.c
M hw/ppc/spapr_rtas.c
Log Message:
-----------
spapr: Clean up handling of LPCR power-saving exit bits
To prevent spurious wakeups on cpus that are supposed to be disabled, we
need to clear the LPCR bits which control certain wakeup events.
spapr_cpu_reset() has separate cases here for boot and non-boot (initially
inactive) cpus. rtas_start_cpu() then turns the LPCR bits on when the
non-boot cpus are activated.
But explicit checks against first_cpu are not how we usually do things:
instead spapr_cpu_reset() generally sets things up for non-boot (inactive)
cpus, then spapr_machine_reset() and/or rtas_start_cpu() override as
necessary.
So, do that instead. Because the LPCR activation is identical for boot
cpus and non-boot cpus just activated with rtas_start_cpu() we can put the
code common in spapr_cpu_set_entry_state().
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
Tested-by: Cédric Le Goater <c...@kaod.org>
Commit: 0662946aa6d3129e7974d4484fc94ab2a5b15d4e
https://github.com/qemu/qemu/commit/0662946aa6d3129e7974d4484fc94ab2a5b15d4e
Author: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/pci-host/trace-events
M hw/pci-host/uninorth.c
M hw/ppc/mac_newworld.c
M hw/ppc/trace-events
M include/hw/pci-host/uninorth.h
Log Message:
-----------
uninorth: create new uninorth device
Commit 4e46dcdbd3 "PPC: Newworld: Add uninorth token register" added a TODO
which was to convert the uninorth registers hack to a proper device. Move
these registers to a new uninorth device, removing the old hacks from
mac_newworld.c.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: 040b27c0b9e593573736d1f5bb804675f02b8816
https://github.com/qemu/qemu/commit/040b27c0b9e593573736d1f5bb804675f02b8816
Author: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/mac.h
M hw/ppc/mac_newworld.c
Log Message:
-----------
mac_newworld: remove pics IRQ array and wire up macio to OpenPIC directly
Introduce constants for the pre-defined New World IRQs to help keep things
readable.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: 0fcd2a814aa331f87fd099171ae03a61311bdfee
https://github.com/qemu/qemu/commit/0fcd2a814aa331f87fd099171ae03a61311bdfee
Author: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/misc/macio/macio.c
M hw/ppc/mac_newworld.c
M include/hw/misc/macio/macio.h
Log Message:
-----------
mac_newworld: move wiring of macio IRQs to macio_newworld_realize()
Since the macio device has a link to the PIC device, we can now wire up the
IRQs directly via qdev GPIOs rather than having to use an intermediate array.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: bce009645b9f1d59195518e35747c8ea30f985f7
https://github.com/qemu/qemu/commit/bce009645b9f1d59195518e35747c8ea30f985f7
Author: Greg Kurz <gr...@kaod.org>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M target/ppc/machine.c
Log Message:
-----------
target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
The pseries-2.7 and older machine types require CPUPPCState::insns_flags
to be strictly equal between source and destination. This checking is
abusive and breaks migration of KVM guests when the host CPU models
are different, even if they are compatible enough to allow the guest
to run transparently. This buggy behaviour was fixed for pseries-2.8
and we added some hacks to allow backward migration of older machine
types. These hacks assume that the CPU belongs to the POWER8 family,
which was true for most KVM based setup we cared about at the time.
But now POWER9 systems are coming, and backward migration of pre 2.8
guests running in POWER8 architected mode from a POWER9 host to a
POWER8 host is broken:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'cpu'
qemu-system-ppc64: load of migration failed: Invalid argument
This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
fix the issue. This is an acceptable hack because these old machine
types only support CPU models that do set PPC_MEM_TLBIE.
Signed-off-by: Greg Kurz <gr...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: aef19c04bf88e0f5f936301e6c29b239e488fbc6
https://github.com/qemu/qemu/commit/aef19c04bf88e0f5f936301e6c29b239e488fbc6
Author: Greg Kurz <gr...@kaod.org>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines
a324d6f16697 "spapr: Support ibm,dynamic-memory-v2 property" added
a new feature in the set of CAS-negotiatable options. This causes
the CAS-negotiated options subsection to be migrated, even for old
machine types that don't know about it, and breaks backward migration
to QEMU 2.7 and older versions:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory
Since this feature only affects boot time behaviour, it should be
filtered out when we decide to migrate CAS-negotiated options, like
we already do with OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY.
Signed-off-by: Greg Kurz <gr...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: 0550b1206a91d66051a21441a02c4ff126b531fe
https://github.com/qemu/qemu/commit/0550b1206a91d66051a21441a02c4ff126b531fe
Author: Greg Kurz <gr...@kaod.org>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: don't advertise radix GTSE if max-compat-cpu < power9
On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily
uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in
the ibm,arch-vec-5-platform-support DT property as the current code does.
The first reason is that it doesn't make sense, and the second one is that
causes the CAS-negotiated options subsection to be migrated. This breaks
backward migration to QEMU 2.7 and older versions on POWER8 hosts:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory
This patch hence initialize CPUs a bit earlier so that we can check the
requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and
older.
Signed-off-by: Greg Kurz <gr...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Commit: 2e4bd4a286ccfadc41165aea413f0abc28beed3e
https://github.com/qemu/qemu/commit/2e4bd4a286ccfadc41165aea413f0abc28beed3e
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2018-05-04 (Fri, 04 May 2018)
Changed paths:
M hw/misc/macio/macio.c
M hw/pci-host/trace-events
M hw/pci-host/uninorth.c
M hw/ppc/mac.h
M hw/ppc/mac_newworld.c
M hw/ppc/spapr.c
M hw/ppc/spapr_cpu_core.c
M hw/ppc/spapr_hcall.c
M hw/ppc/spapr_rtas.c
M hw/ppc/trace-events
M include/hw/misc/macio/macio.h
M include/hw/pci-host/uninorth.h
M include/hw/ppc/spapr_cpu_core.h
M target/ppc/cpu.h
M target/ppc/helper.h
M target/ppc/kvm.c
M target/ppc/kvm_ppc.h
M target/ppc/machine.c
M target/ppc/misc_helper.c
M target/ppc/mmu-book3s-v3.h
M target/ppc/mmu-hash64.c
M target/ppc/mmu-hash64.h
M target/ppc/mmu_helper.c
M target/ppc/translate.c
M target/ppc/translate_init.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.13-20180504'
into staging
ppc patch queue 2018-05-04
Second patch of patches for qemu-2.13 (or whatever the version ends up
being called). Highlights are:
* Preliminary patches for POWER9 hash MMU support for powernv
* A number of cleanups fo pseries startup and LPCR handling
* Remove support for explicitly allocated RMAs (which require kernel
support that's been gone for 3+ years)
* Some mac_newworld cleanups
* A few bugfixes
# gpg: Signature made Fri 04 May 2018 06:07:43 BST
# gpg: using RSA key 6C38CACA20D9B392
# gpg: Good signature from "David Gibson <da...@gibson.dropbear.id.au>"
# gpg: aka "David Gibson (Red Hat) <dgib...@redhat.com>"
# gpg: aka "David Gibson (ozlabs.org) <dgib...@ozlabs.org>"
# gpg: aka "David Gibson (kernel.org) <d...@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-2.13-20180504:
spapr: don't advertise radix GTSE if max-compat-cpu < power9
spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines
target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
mac_newworld: move wiring of macio IRQs to macio_newworld_realize()
mac_newworld: remove pics IRQ array and wire up macio to OpenPIC directly
uninorth: create new uninorth device
spapr: Clean up handling of LPCR power-saving exit bits
spapr: Move PAPR mode cpu setup fully to spapr code
target/ppc: Delay initialization of LPCR_UPRT for secondary cpus
spapr: Clean up LPCR updates from hypercalls
spapr: Make a helper to set up cpu entry point state
spapr: Remove unhelpful helpers from rtas_start_cpu()
spapr: Clean up rtas_start_cpu() & rtas_stop_self()
target/ppc: Add ppc_store_lpcr() helper
spapr: Remove support for explicitly allocated RMAs
target/ppc: add basic support for PTCR on POWER9
target/ppc: return a nil HPT base address on sPAPR machines
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Compare: https://github.com/qemu/qemu/compare/f0c889522255...2e4bd4a286cc
**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.
