2013-03-12 04:31:06 +04:00
|
|
|
/*
|
|
|
|
* PowerPC MMU, TLB, SLB and BAT emulation helpers for QEMU.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2007 Jocelyn Mayer
|
|
|
|
* Copyright (c) 2013 David Gibson, IBM Corporation
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
2020-10-19 09:11:26 +03:00
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2013-03-12 04:31:06 +04:00
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
2016-01-26 21:16:58 +03:00
|
|
|
#include "qemu/osdep.h"
|
2020-01-06 08:52:26 +03:00
|
|
|
#include "qemu/units.h"
|
2013-03-12 04:31:06 +04:00
|
|
|
#include "cpu.h"
|
2016-03-15 15:18:37 +03:00
|
|
|
#include "exec/exec-all.h"
|
2014-04-08 09:31:41 +04:00
|
|
|
#include "exec/helper-proto.h"
|
2016-01-27 03:52:57 +03:00
|
|
|
#include "qemu/error-report.h"
|
2019-04-17 22:17:58 +03:00
|
|
|
#include "qemu/qemu-print.h"
|
2017-01-10 13:59:55 +03:00
|
|
|
#include "sysemu/hw_accel.h"
|
2013-03-12 04:31:06 +04:00
|
|
|
#include "kvm_ppc.h"
|
|
|
|
#include "mmu-hash64.h"
|
2016-01-07 16:55:28 +03:00
|
|
|
#include "exec/log.h"
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
#include "hw/hw.h"
|
2017-03-01 09:54:38 +03:00
|
|
|
#include "mmu-book3s-v3.h"
|
2021-03-23 21:43:36 +03:00
|
|
|
#include "helper_regs.h"
|
2013-03-12 04:31:06 +04:00
|
|
|
|
2019-03-21 14:32:53 +03:00
|
|
|
/* #define DEBUG_SLB */
|
2013-03-12 04:31:06 +04:00
|
|
|
|
|
|
|
#ifdef DEBUG_SLB
|
2015-11-13 15:34:23 +03:00
|
|
|
# define LOG_SLB(...) qemu_log_mask(CPU_LOG_MMU, __VA_ARGS__)
|
2013-03-12 04:31:06 +04:00
|
|
|
#else
|
|
|
|
# define LOG_SLB(...) do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SLB handling
|
|
|
|
*/
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
static ppc_slb_t *slb_lookup(PowerPCCPU *cpu, target_ulong eaddr)
|
2013-03-12 04:31:06 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:06 +04:00
|
|
|
uint64_t esid_256M, esid_1T;
|
|
|
|
int n;
|
|
|
|
|
|
|
|
LOG_SLB("%s: eaddr " TARGET_FMT_lx "\n", __func__, eaddr);
|
|
|
|
|
|
|
|
esid_256M = (eaddr & SEGMENT_MASK_256M) | SLB_ESID_V;
|
|
|
|
esid_1T = (eaddr & SEGMENT_MASK_1T) | SLB_ESID_V;
|
|
|
|
|
2018-03-29 10:29:38 +03:00
|
|
|
for (n = 0; n < cpu->hash64_opts->slb_size; n++) {
|
2013-03-12 04:31:06 +04:00
|
|
|
ppc_slb_t *slb = &env->slb[n];
|
|
|
|
|
|
|
|
LOG_SLB("%s: slot %d %016" PRIx64 " %016"
|
|
|
|
PRIx64 "\n", __func__, n, slb->esid, slb->vsid);
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* We check for 1T matches on all MMUs here - if the MMU
|
2013-03-12 04:31:06 +04:00
|
|
|
* doesn't have 1T segment support, we will have prevented 1T
|
2019-03-21 14:32:53 +03:00
|
|
|
* entries from being inserted in the slbmte code.
|
|
|
|
*/
|
2013-03-12 04:31:06 +04:00
|
|
|
if (((slb->esid == esid_256M) &&
|
|
|
|
((slb->vsid & SLB_VSID_B) == SLB_VSID_B_256M))
|
|
|
|
|| ((slb->esid == esid_1T) &&
|
|
|
|
((slb->vsid & SLB_VSID_B) == SLB_VSID_B_1T))) {
|
|
|
|
return slb;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-04-17 22:17:58 +03:00
|
|
|
void dump_slb(PowerPCCPU *cpu)
|
2013-03-12 04:31:06 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:06 +04:00
|
|
|
int i;
|
|
|
|
uint64_t slbe, slbv;
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
cpu_synchronize_state(CPU(cpu));
|
2013-03-12 04:31:06 +04:00
|
|
|
|
2019-04-17 22:17:58 +03:00
|
|
|
qemu_printf("SLB\tESID\t\t\tVSID\n");
|
2018-03-29 10:29:38 +03:00
|
|
|
for (i = 0; i < cpu->hash64_opts->slb_size; i++) {
|
2013-03-12 04:31:06 +04:00
|
|
|
slbe = env->slb[i].esid;
|
|
|
|
slbv = env->slb[i].vsid;
|
|
|
|
if (slbe == 0 && slbv == 0) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 22:17:58 +03:00
|
|
|
qemu_printf("%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
|
2013-03-12 04:31:06 +04:00
|
|
|
i, slbe, slbv);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-19 09:44:39 +03:00
|
|
|
void helper_slbia(CPUPPCState *env, uint32_t ih)
|
2013-03-12 04:31:06 +04:00
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2020-03-19 09:44:39 +03:00
|
|
|
int starting_entry;
|
ppc: Do some batching of TCG tlb flushes
On ppc64 especially, we flush the tlb on any slbie or tlbie instruction.
However, those instructions often come in bursts of 3 or more (context
switch will favor a series of slbie's for example to an slbia if the
SLB has less than a certain number of entries in it, and tlbie's can
happen in a series, with PAPR, H_BULK_REMOVE can remove up to 4 entries
at a time.
Doing a tlb_flush() each time is a waste of time. We end up doing a memset
of the whole TLB, reloading it for the next instruction, memset'ing again,
etc...
Those instructions don't have to take effect immediately. For slbie, they
can wait for the next context synchronizing event. For tlbie, the next
tlbsync.
This implements batching by keeping a flag that indicates that we have a
TLB in need of flushing. We check it on interrupts, rfi's, isync's and
tlbsync and flush the TLB if needed.
This reduces the number of tlb_flush() on a boot to a ubuntu installer
first dialog screen from roughly 360K down to 36K.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[clg: added a 'CPUPPCState *' variable in h_remove() and
h_bulk_remove() ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: removed spurious whitespace change, use 0/1 not true/false
consistently, since tlb_need_flush has int type]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-05-03 19:03:25 +03:00
|
|
|
int n;
|
2013-03-12 04:31:06 +04:00
|
|
|
|
2020-03-18 07:41:34 +03:00
|
|
|
/*
|
|
|
|
* slbia must always flush all TLB (which is equivalent to ERAT in ppc
|
|
|
|
* architecture). Matching on SLB_ESID_V is not good enough, because slbmte
|
|
|
|
* can overwrite a valid SLB without flushing its lookaside information.
|
|
|
|
*
|
|
|
|
* It would be possible to keep the TLB in synch with the SLB by flushing
|
|
|
|
* when a valid entry is overwritten by slbmte, and therefore slbia would
|
|
|
|
* not have to flush unless it evicts a valid SLB entry. However it is
|
|
|
|
* expected that slbmte is more common than slbia, and slbia is usually
|
|
|
|
* going to evict valid SLB entries, so that tradeoff is unlikely to be a
|
|
|
|
* good one.
|
2020-03-19 09:44:39 +03:00
|
|
|
*
|
|
|
|
* ISA v2.05 introduced IH field with values 0,1,2,6. These all invalidate
|
|
|
|
* the same SLB entries (everything but entry 0), but differ in what
|
|
|
|
* "lookaside information" is invalidated. TCG can ignore this and flush
|
|
|
|
* everything.
|
|
|
|
*
|
|
|
|
* ISA v3.0 introduced additional values 3,4,7, which change what SLBs are
|
|
|
|
* invalidated.
|
2020-03-18 07:41:34 +03:00
|
|
|
*/
|
|
|
|
|
2020-03-19 09:44:39 +03:00
|
|
|
env->tlb_need_flush |= TLB_NEED_LOCAL_FLUSH;
|
2013-03-12 04:31:06 +04:00
|
|
|
|
2020-03-19 09:44:39 +03:00
|
|
|
starting_entry = 1; /* default for IH=0,1,2,6 */
|
|
|
|
|
|
|
|
if (env->mmu_model == POWERPC_MMU_3_00) {
|
|
|
|
switch (ih) {
|
|
|
|
case 0x7:
|
|
|
|
/* invalidate no SLBs, but all lookaside information */
|
|
|
|
return;
|
|
|
|
|
|
|
|
case 0x3:
|
|
|
|
case 0x4:
|
|
|
|
/* also considers SLB entry 0 */
|
|
|
|
starting_entry = 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5:
|
|
|
|
/* treat undefined values as ih==0, and warn */
|
|
|
|
qemu_log_mask(LOG_GUEST_ERROR,
|
|
|
|
"slbia undefined IH field %u.\n", ih);
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
/* 0,1,2,6 */
|
|
|
|
break;
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
|
|
|
}
|
2020-03-18 07:41:34 +03:00
|
|
|
|
2020-03-19 09:44:39 +03:00
|
|
|
for (n = starting_entry; n < cpu->hash64_opts->slb_size; n++) {
|
|
|
|
ppc_slb_t *slb = &env->slb[n];
|
|
|
|
|
|
|
|
if (!(slb->esid & SLB_ESID_V)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (env->mmu_model == POWERPC_MMU_3_00) {
|
|
|
|
if (ih == 0x3 && (slb->vsid & SLB_VSID_C) == 0) {
|
|
|
|
/* preserves entries with a class value of 0 */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
slb->esid &= ~SLB_ESID_V;
|
|
|
|
}
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
|
|
|
|
2017-02-09 13:34:01 +03:00
|
|
|
static void __helper_slbie(CPUPPCState *env, target_ulong addr,
|
|
|
|
target_ulong global)
|
2013-03-12 04:31:06 +04:00
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2013-03-12 04:31:06 +04:00
|
|
|
ppc_slb_t *slb;
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
slb = slb_lookup(cpu, addr);
|
2013-03-12 04:31:06 +04:00
|
|
|
if (!slb) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (slb->esid & SLB_ESID_V) {
|
|
|
|
slb->esid &= ~SLB_ESID_V;
|
|
|
|
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* XXX: given the fact that segment size is 256 MB or 1TB,
|
2013-03-12 04:31:06 +04:00
|
|
|
* and we still don't have a tlb_flush_mask(env, n, mask)
|
|
|
|
* in QEMU, we just invalidate all TLBs
|
|
|
|
*/
|
2017-02-09 13:34:01 +03:00
|
|
|
env->tlb_need_flush |=
|
|
|
|
(global == false ? TLB_NEED_LOCAL_FLUSH : TLB_NEED_GLOBAL_FLUSH);
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-09 13:34:01 +03:00
|
|
|
void helper_slbie(CPUPPCState *env, target_ulong addr)
|
|
|
|
{
|
|
|
|
__helper_slbie(env, addr, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
void helper_slbieg(CPUPPCState *env, target_ulong addr)
|
|
|
|
{
|
|
|
|
__helper_slbie(env, addr, true);
|
|
|
|
}
|
|
|
|
|
2016-01-27 03:07:29 +03:00
|
|
|
int ppc_store_slb(PowerPCCPU *cpu, target_ulong slot,
|
|
|
|
target_ulong esid, target_ulong vsid)
|
2013-03-12 04:31:06 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:06 +04:00
|
|
|
ppc_slb_t *slb = &env->slb[slot];
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64SegmentPageSizes *sps = NULL;
|
2016-01-27 03:52:57 +03:00
|
|
|
int i;
|
2013-03-12 04:31:06 +04:00
|
|
|
|
2018-03-29 10:29:38 +03:00
|
|
|
if (slot >= cpu->hash64_opts->slb_size) {
|
2016-01-27 03:07:29 +03:00
|
|
|
return -1; /* Bad slot number */
|
|
|
|
}
|
|
|
|
if (esid & ~(SLB_ESID_ESID | SLB_ESID_V)) {
|
|
|
|
return -1; /* Reserved bits set */
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
2016-01-27 03:07:29 +03:00
|
|
|
if (vsid & (SLB_VSID_B & ~SLB_VSID_B_1T)) {
|
2013-03-12 04:31:06 +04:00
|
|
|
return -1; /* Bad segment size */
|
|
|
|
}
|
2018-03-23 06:11:07 +03:00
|
|
|
if ((vsid & SLB_VSID_B) && !(ppc_hash64_has(cpu, PPC_HASH64_1TSEG))) {
|
2013-03-12 04:31:06 +04:00
|
|
|
return -1; /* 1T segment on MMU that doesn't support it */
|
|
|
|
}
|
|
|
|
|
2016-01-27 03:52:57 +03:00
|
|
|
for (i = 0; i < PPC_PAGE_SIZES_MAX_SZ; i++) {
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64SegmentPageSizes *sps1 = &cpu->hash64_opts->sps[i];
|
2016-01-27 03:52:57 +03:00
|
|
|
|
|
|
|
if (!sps1->page_shift) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((vsid & SLB_VSID_LLP_MASK) == sps1->slb_enc) {
|
|
|
|
sps = sps1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!sps) {
|
|
|
|
error_report("Bad page size encoding in SLB store: slot "TARGET_FMT_lu
|
|
|
|
" esid 0x"TARGET_FMT_lx" vsid 0x"TARGET_FMT_lx,
|
|
|
|
slot, esid, vsid);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-01-27 03:07:29 +03:00
|
|
|
slb->esid = esid;
|
|
|
|
slb->vsid = vsid;
|
2016-01-27 03:52:57 +03:00
|
|
|
slb->sps = sps;
|
2013-03-12 04:31:06 +04:00
|
|
|
|
2017-01-13 09:28:22 +03:00
|
|
|
LOG_SLB("%s: " TARGET_FMT_lu " " TARGET_FMT_lx " - " TARGET_FMT_lx
|
|
|
|
" => %016" PRIx64 " %016" PRIx64 "\n", __func__, slot, esid, vsid,
|
2013-03-12 04:31:06 +04:00
|
|
|
slb->esid, slb->vsid);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
static int ppc_load_slb_esid(PowerPCCPU *cpu, target_ulong rb,
|
2013-03-12 04:31:06 +04:00
|
|
|
target_ulong *rt)
|
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:06 +04:00
|
|
|
int slot = rb & 0xfff;
|
|
|
|
ppc_slb_t *slb = &env->slb[slot];
|
|
|
|
|
2018-03-29 10:29:38 +03:00
|
|
|
if (slot >= cpu->hash64_opts->slb_size) {
|
2013-03-12 04:31:06 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
*rt = slb->esid;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
static int ppc_load_slb_vsid(PowerPCCPU *cpu, target_ulong rb,
|
2013-03-12 04:31:06 +04:00
|
|
|
target_ulong *rt)
|
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:06 +04:00
|
|
|
int slot = rb & 0xfff;
|
|
|
|
ppc_slb_t *slb = &env->slb[slot];
|
|
|
|
|
2018-03-29 10:29:38 +03:00
|
|
|
if (slot >= cpu->hash64_opts->slb_size) {
|
2013-03-12 04:31:06 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
*rt = slb->vsid;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-07 05:50:27 +03:00
|
|
|
static int ppc_find_slb_vsid(PowerPCCPU *cpu, target_ulong rb,
|
|
|
|
target_ulong *rt)
|
|
|
|
{
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
ppc_slb_t *slb;
|
|
|
|
|
|
|
|
if (!msr_is_64bit(env, env->msr)) {
|
|
|
|
rb &= 0xffffffff;
|
|
|
|
}
|
|
|
|
slb = slb_lookup(cpu, rb);
|
|
|
|
if (slb == NULL) {
|
|
|
|
*rt = (target_ulong)-1ul;
|
|
|
|
} else {
|
|
|
|
*rt = slb->vsid;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-12 04:31:06 +04:00
|
|
|
void helper_store_slb(CPUPPCState *env, target_ulong rb, target_ulong rs)
|
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2016-01-14 07:33:27 +03:00
|
|
|
|
2016-01-27 03:07:29 +03:00
|
|
|
if (ppc_store_slb(cpu, rb & 0xfff, rb & ~0xfffULL, rs) < 0) {
|
2016-07-27 09:56:34 +03:00
|
|
|
raise_exception_err_ra(env, POWERPC_EXCP_PROGRAM,
|
|
|
|
POWERPC_EXCP_INVAL, GETPC());
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
target_ulong helper_load_slb_esid(CPUPPCState *env, target_ulong rb)
|
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2013-03-12 04:31:06 +04:00
|
|
|
target_ulong rt = 0;
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
if (ppc_load_slb_esid(cpu, rb, &rt) < 0) {
|
2016-07-27 09:56:34 +03:00
|
|
|
raise_exception_err_ra(env, POWERPC_EXCP_PROGRAM,
|
|
|
|
POWERPC_EXCP_INVAL, GETPC());
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
|
|
|
return rt;
|
|
|
|
}
|
|
|
|
|
2016-06-07 05:50:27 +03:00
|
|
|
target_ulong helper_find_slb_vsid(CPUPPCState *env, target_ulong rb)
|
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2016-06-07 05:50:27 +03:00
|
|
|
target_ulong rt = 0;
|
|
|
|
|
|
|
|
if (ppc_find_slb_vsid(cpu, rb, &rt) < 0) {
|
2016-07-27 09:56:34 +03:00
|
|
|
raise_exception_err_ra(env, POWERPC_EXCP_PROGRAM,
|
|
|
|
POWERPC_EXCP_INVAL, GETPC());
|
2016-06-07 05:50:27 +03:00
|
|
|
}
|
|
|
|
return rt;
|
|
|
|
}
|
|
|
|
|
2013-03-12 04:31:06 +04:00
|
|
|
target_ulong helper_load_slb_vsid(CPUPPCState *env, target_ulong rb)
|
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2013-03-12 04:31:06 +04:00
|
|
|
target_ulong rt = 0;
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
if (ppc_load_slb_vsid(cpu, rb, &rt) < 0) {
|
2016-07-27 09:56:34 +03:00
|
|
|
raise_exception_err_ra(env, POWERPC_EXCP_PROGRAM,
|
|
|
|
POWERPC_EXCP_INVAL, GETPC());
|
2013-03-12 04:31:06 +04:00
|
|
|
}
|
|
|
|
return rt;
|
|
|
|
}
|
2013-03-12 04:31:07 +04:00
|
|
|
|
2017-03-01 10:12:54 +03:00
|
|
|
/* Check No-Execute or Guarded Storage */
|
|
|
|
static inline int ppc_hash64_pte_noexec_guard(PowerPCCPU *cpu,
|
|
|
|
ppc_hash_pte64_t pte)
|
|
|
|
{
|
|
|
|
/* Exec permissions CANNOT take away read or write permissions */
|
|
|
|
return (pte.pte1 & HPTE64_R_N) || (pte.pte1 & HPTE64_R_G) ?
|
|
|
|
PAGE_READ | PAGE_WRITE : PAGE_READ | PAGE_WRITE | PAGE_EXEC;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check Basic Storage Protection */
|
2016-01-14 07:33:27 +03:00
|
|
|
static int ppc_hash64_pte_prot(PowerPCCPU *cpu,
|
2013-03-12 04:31:40 +04:00
|
|
|
ppc_slb_t *slb, ppc_hash_pte64_t pte)
|
2013-03-12 04:31:14 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:40 +04:00
|
|
|
unsigned pp, key;
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* Some pp bit combinations have undefined behaviour, so default
|
|
|
|
* to no access in those cases
|
|
|
|
*/
|
2013-03-12 04:31:40 +04:00
|
|
|
int prot = 0;
|
|
|
|
|
|
|
|
key = !!(msr_pr ? (slb->vsid & SLB_VSID_KP)
|
|
|
|
: (slb->vsid & SLB_VSID_KS));
|
|
|
|
pp = (pte.pte1 & HPTE64_R_PP) | ((pte.pte1 & HPTE64_R_PP0) >> 61);
|
2013-03-12 04:31:14 +04:00
|
|
|
|
|
|
|
if (key == 0) {
|
|
|
|
switch (pp) {
|
|
|
|
case 0x0:
|
|
|
|
case 0x1:
|
|
|
|
case 0x2:
|
2017-03-01 10:12:53 +03:00
|
|
|
prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
|
2013-03-12 04:31:40 +04:00
|
|
|
break;
|
|
|
|
|
2013-03-12 04:31:14 +04:00
|
|
|
case 0x3:
|
|
|
|
case 0x6:
|
2017-03-01 10:12:53 +03:00
|
|
|
prot = PAGE_READ | PAGE_EXEC;
|
2013-03-12 04:31:14 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
switch (pp) {
|
|
|
|
case 0x0:
|
|
|
|
case 0x6:
|
|
|
|
break;
|
2013-03-12 04:31:40 +04:00
|
|
|
|
2013-03-12 04:31:14 +04:00
|
|
|
case 0x1:
|
|
|
|
case 0x3:
|
2017-03-01 10:12:53 +03:00
|
|
|
prot = PAGE_READ | PAGE_EXEC;
|
2013-03-12 04:31:14 +04:00
|
|
|
break;
|
2013-03-12 04:31:40 +04:00
|
|
|
|
2013-03-12 04:31:14 +04:00
|
|
|
case 0x2:
|
2017-03-01 10:12:53 +03:00
|
|
|
prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
|
2013-03-12 04:31:14 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-12 04:31:40 +04:00
|
|
|
return prot;
|
2013-03-12 04:31:14 +04:00
|
|
|
}
|
|
|
|
|
2017-03-01 10:12:52 +03:00
|
|
|
/* Check the instruction access permissions specified in the IAMR */
|
|
|
|
static int ppc_hash64_iamr_prot(PowerPCCPU *cpu, int key)
|
|
|
|
{
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
int iamr_bits = (env->spr[SPR_IAMR] >> 2 * (31 - key)) & 0x3;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* An instruction fetch is permitted if the IAMR bit is 0.
|
|
|
|
* If the bit is set, return PAGE_READ | PAGE_WRITE because this bit
|
|
|
|
* can only take away EXEC permissions not READ or WRITE permissions.
|
|
|
|
* If bit is cleared return PAGE_READ | PAGE_WRITE | PAGE_EXEC since
|
|
|
|
* EXEC permissions are allowed.
|
|
|
|
*/
|
|
|
|
return (iamr_bits & 0x1) ? PAGE_READ | PAGE_WRITE :
|
|
|
|
PAGE_READ | PAGE_WRITE | PAGE_EXEC;
|
|
|
|
}
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
static int ppc_hash64_amr_prot(PowerPCCPU *cpu, ppc_hash_pte64_t pte)
|
2013-03-12 04:31:47 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2013-03-12 04:31:47 +04:00
|
|
|
int key, amrbits;
|
2014-02-04 21:21:39 +04:00
|
|
|
int prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
|
2013-03-12 04:31:47 +04:00
|
|
|
|
|
|
|
/* Only recent MMUs implement Virtual Page Class Key Protection */
|
2018-03-23 06:11:07 +03:00
|
|
|
if (!ppc_hash64_has(cpu, PPC_HASH64_AMR)) {
|
2014-02-04 21:21:39 +04:00
|
|
|
return prot;
|
2013-03-12 04:31:47 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
key = HPTE64_R_KEY(pte.pte1);
|
2019-03-21 14:32:53 +03:00
|
|
|
amrbits = (env->spr[SPR_AMR] >> 2 * (31 - key)) & 0x3;
|
2013-03-12 04:31:47 +04:00
|
|
|
|
|
|
|
/* fprintf(stderr, "AMR protection: key=%d AMR=0x%" PRIx64 "\n", key, */
|
|
|
|
/* env->spr[SPR_AMR]); */
|
|
|
|
|
2014-02-04 21:21:39 +04:00
|
|
|
/*
|
|
|
|
* A store is permitted if the AMR bit is 0. Remove write
|
|
|
|
* protection if it is set.
|
|
|
|
*/
|
2013-03-12 04:31:47 +04:00
|
|
|
if (amrbits & 0x2) {
|
2014-02-04 21:21:39 +04:00
|
|
|
prot &= ~PAGE_WRITE;
|
2013-03-12 04:31:47 +04:00
|
|
|
}
|
2014-02-04 21:21:39 +04:00
|
|
|
/*
|
|
|
|
* A load is permitted if the AMR bit is 0. Remove read
|
|
|
|
* protection if it is set.
|
|
|
|
*/
|
2013-03-12 04:31:47 +04:00
|
|
|
if (amrbits & 0x1) {
|
2014-02-04 21:21:39 +04:00
|
|
|
prot &= ~PAGE_READ;
|
2013-03-12 04:31:47 +04:00
|
|
|
}
|
|
|
|
|
2017-03-01 10:12:52 +03:00
|
|
|
switch (env->mmu_model) {
|
|
|
|
/*
|
|
|
|
* MMU version 2.07 and later support IAMR
|
|
|
|
* Check if the IAMR allows the instruction access - it will return
|
|
|
|
* PAGE_EXEC if it doesn't (and thus that bit will be cleared) or 0
|
|
|
|
* if it does (and prot will be unchanged indicating execution support).
|
|
|
|
*/
|
|
|
|
case POWERPC_MMU_2_07:
|
|
|
|
case POWERPC_MMU_3_00:
|
|
|
|
prot &= ppc_hash64_iamr_prot(cpu, key);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-03-12 04:31:47 +04:00
|
|
|
return prot;
|
|
|
|
}
|
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
const ppc_hash_pte64_t *ppc_hash64_map_hptes(PowerPCCPU *cpu,
|
|
|
|
hwaddr ptex, int n)
|
2014-02-20 21:52:24 +04:00
|
|
|
{
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
hwaddr pte_offset = ptex * HASH_PTE_SIZE_64;
|
2019-02-15 20:00:28 +03:00
|
|
|
hwaddr base;
|
2017-02-23 03:39:18 +03:00
|
|
|
hwaddr plen = n * HASH_PTE_SIZE_64;
|
|
|
|
const ppc_hash_pte64_t *hptes;
|
2014-02-20 21:52:24 +04:00
|
|
|
|
2017-02-23 03:39:18 +03:00
|
|
|
if (cpu->vhyp) {
|
|
|
|
PPCVirtualHypervisorClass *vhc =
|
|
|
|
PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
|
|
|
|
return vhc->map_hptes(cpu->vhyp, ptex, n);
|
|
|
|
}
|
2019-02-15 20:00:28 +03:00
|
|
|
base = ppc_hash64_hpt_base(cpu);
|
2017-02-23 03:39:18 +03:00
|
|
|
|
|
|
|
if (!base) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-05-31 16:50:52 +03:00
|
|
|
hptes = address_space_map(CPU(cpu)->as, base + pte_offset, &plen, false,
|
|
|
|
MEMTXATTRS_UNSPECIFIED);
|
2017-02-23 03:39:18 +03:00
|
|
|
if (plen < (n * HASH_PTE_SIZE_64)) {
|
|
|
|
hw_error("%s: Unable to map all requested HPTEs\n", __func__);
|
2014-02-20 21:52:24 +04:00
|
|
|
}
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
return hptes;
|
2014-02-20 21:52:24 +04:00
|
|
|
}
|
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
void ppc_hash64_unmap_hptes(PowerPCCPU *cpu, const ppc_hash_pte64_t *hptes,
|
|
|
|
hwaddr ptex, int n)
|
2014-02-20 21:52:24 +04:00
|
|
|
{
|
2017-02-23 03:39:18 +03:00
|
|
|
if (cpu->vhyp) {
|
|
|
|
PPCVirtualHypervisorClass *vhc =
|
|
|
|
PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
|
|
|
|
vhc->unmap_hptes(cpu->vhyp, hptes, ptex, n);
|
|
|
|
return;
|
2014-02-20 21:52:24 +04:00
|
|
|
}
|
2017-02-23 03:39:18 +03:00
|
|
|
|
|
|
|
address_space_unmap(CPU(cpu)->as, (void *)hptes, n * HASH_PTE_SIZE_64,
|
|
|
|
false, n * HASH_PTE_SIZE_64);
|
2014-02-20 21:52:24 +04:00
|
|
|
}
|
|
|
|
|
2018-03-23 05:31:52 +03:00
|
|
|
static unsigned hpte_page_shift(const PPCHash64SegmentPageSizes *sps,
|
|
|
|
uint64_t pte0, uint64_t pte1)
|
2016-06-28 09:48:34 +03:00
|
|
|
{
|
2016-07-05 05:17:56 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!(pte0 & HPTE64_V_LARGE)) {
|
|
|
|
if (sps->page_shift != 12) {
|
|
|
|
/* 4kiB page in a non 4kiB segment */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* Normal 4kiB page */
|
2016-06-28 09:48:34 +03:00
|
|
|
return 12;
|
2016-07-05 05:17:56 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < PPC_PAGE_SIZES_MAX_SZ; i++) {
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64PageSize *ps = &sps->enc[i];
|
2016-07-05 05:17:56 +03:00
|
|
|
uint64_t mask;
|
|
|
|
|
|
|
|
if (!ps->page_shift) {
|
|
|
|
break;
|
2016-06-28 09:48:34 +03:00
|
|
|
}
|
2016-07-05 05:17:56 +03:00
|
|
|
|
|
|
|
if (ps->page_shift == 12) {
|
|
|
|
/* L bit is set so this can't be a 4kiB page */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
mask = ((1ULL << ps->page_shift) - 1) & HPTE64_R_RPN;
|
|
|
|
|
2016-07-15 18:22:10 +03:00
|
|
|
if ((pte1 & mask) == ((uint64_t)ps->pte_enc << HPTE64_R_RPN_SHIFT)) {
|
2016-07-05 05:17:56 +03:00
|
|
|
return ps->page_shift;
|
2016-06-28 09:48:34 +03:00
|
|
|
}
|
|
|
|
}
|
2016-07-05 05:17:56 +03:00
|
|
|
|
|
|
|
return 0; /* Bad page size encoding */
|
2016-06-28 09:48:34 +03:00
|
|
|
}
|
|
|
|
|
2019-02-15 20:00:24 +03:00
|
|
|
static void ppc64_v3_new_to_old_hpte(target_ulong *pte0, target_ulong *pte1)
|
|
|
|
{
|
|
|
|
/* Insert B into pte0 */
|
|
|
|
*pte0 = (*pte0 & HPTE64_V_COMMON_BITS) |
|
|
|
|
((*pte1 & HPTE64_R_3_0_SSIZE_MASK) <<
|
|
|
|
(HPTE64_V_SSIZE_SHIFT - HPTE64_R_3_0_SSIZE_SHIFT));
|
|
|
|
|
|
|
|
/* Remove B from pte1 */
|
|
|
|
*pte1 = *pte1 & ~HPTE64_R_3_0_SSIZE_MASK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
static hwaddr ppc_hash64_pteg_search(PowerPCCPU *cpu, hwaddr hash,
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64SegmentPageSizes *sps,
|
2016-07-04 10:44:11 +03:00
|
|
|
target_ulong ptem,
|
2016-07-05 05:31:57 +03:00
|
|
|
ppc_hash_pte64_t *pte, unsigned *pshift)
|
2013-03-12 04:31:28 +04:00
|
|
|
{
|
|
|
|
int i;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
const ppc_hash_pte64_t *pteg;
|
2014-02-20 21:52:24 +04:00
|
|
|
target_ulong pte0, pte1;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
target_ulong ptex;
|
2013-03-12 04:31:28 +04:00
|
|
|
|
target/ppc: Eliminate htab_base and htab_mask variables
CPUPPCState includes fields htab_base and htab_mask which store the base
address (GPA) and size (as a mask) of the guest's hashed page table (HPT).
These are set when the SDR1 register is updated.
Keeping these in sync with the SDR1 is actually a little bit fiddly, and
probably not useful for performance, since keeping them expands the size of
CPUPPCState. It also makes some upcoming changes harder to implement.
This patch removes these fields, in favour of calculating them directly
from the SDR1 contents when necessary.
This does make a change to the behaviour of attempting to write a bad value
(invalid HPT size) to the SDR1 with an mtspr instruction. Previously, the
bad value would be stored in SDR1 and could be retrieved with a later
mfspr, but the HPT size as used by the softmmu would be, clamped to the
allowed values. Now, writing a bad value is treated as a no-op. An error
message is printed in both new and old versions.
I'm not sure which behaviour, if either, matches real hardware. I don't
think it matters that much, since it's pretty clear that if an OS writes
a bad value to SDR1, it's not going to boot.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-02-24 08:36:44 +03:00
|
|
|
ptex = (hash & ppc_hash64_hpt_mask(cpu)) * HPTES_PER_GROUP;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
pteg = ppc_hash64_map_hptes(cpu, ptex, HPTES_PER_GROUP);
|
|
|
|
if (!pteg) {
|
2014-02-20 21:52:24 +04:00
|
|
|
return -1;
|
|
|
|
}
|
2013-03-12 04:31:28 +04:00
|
|
|
for (i = 0; i < HPTES_PER_GROUP; i++) {
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
pte0 = ppc_hash64_hpte0(cpu, pteg, i);
|
2019-02-15 20:00:23 +03:00
|
|
|
/*
|
|
|
|
* pte0 contains the valid bit and must be read before pte1,
|
|
|
|
* otherwise we might see an old pte1 with a new valid bit and
|
|
|
|
* thus an inconsistent hpte value
|
|
|
|
*/
|
|
|
|
smp_rmb();
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
pte1 = ppc_hash64_hpte1(cpu, pteg, i);
|
2013-03-12 04:31:28 +04:00
|
|
|
|
2019-02-15 20:00:24 +03:00
|
|
|
/* Convert format if necessary */
|
|
|
|
if (cpu->env.mmu_model == POWERPC_MMU_3_00 && !cpu->vhyp) {
|
|
|
|
ppc64_v3_new_to_old_hpte(&pte0, &pte1);
|
|
|
|
}
|
|
|
|
|
2016-07-05 05:31:48 +03:00
|
|
|
/* This compares V, B, H (secondary) and the AVPN */
|
|
|
|
if (HPTE64_V_COMPARE(pte0, ptem)) {
|
2016-07-04 10:44:11 +03:00
|
|
|
*pshift = hpte_page_shift(sps, pte0, pte1);
|
2016-07-05 05:17:56 +03:00
|
|
|
/*
|
|
|
|
* If there is no match, ignore the PTE, it could simply
|
|
|
|
* be for a different segment size encoding and the
|
|
|
|
* architecture specifies we should not match. Linux will
|
|
|
|
* potentially leave behind PTEs for the wrong base page
|
|
|
|
* size when demoting segments.
|
|
|
|
*/
|
2016-07-05 05:31:57 +03:00
|
|
|
if (*pshift == 0) {
|
2016-06-28 09:48:34 +03:00
|
|
|
continue;
|
|
|
|
}
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* We don't do anything with pshift yet as qemu TLB only
|
|
|
|
* deals with 4K pages anyway
|
2016-06-28 09:48:34 +03:00
|
|
|
*/
|
2013-03-12 04:31:28 +04:00
|
|
|
pte->pte0 = pte0;
|
|
|
|
pte->pte1 = pte1;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
ppc_hash64_unmap_hptes(cpu, pteg, ptex, HPTES_PER_GROUP);
|
|
|
|
return ptex + i;
|
2013-03-12 04:31:28 +04:00
|
|
|
}
|
|
|
|
}
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
ppc_hash64_unmap_hptes(cpu, pteg, ptex, HPTES_PER_GROUP);
|
2014-02-20 21:52:24 +04:00
|
|
|
/*
|
|
|
|
* We didn't find a valid entry.
|
|
|
|
*/
|
2013-03-12 04:31:28 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
static hwaddr ppc_hash64_htab_lookup(PowerPCCPU *cpu,
|
2013-03-12 04:31:30 +04:00
|
|
|
ppc_slb_t *slb, target_ulong eaddr,
|
2016-07-05 05:31:57 +03:00
|
|
|
ppc_hash_pte64_t *pte, unsigned *pshift)
|
2013-03-12 04:31:08 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
hwaddr hash, ptex;
|
2016-01-27 03:52:57 +03:00
|
|
|
uint64_t vsid, epnmask, epn, ptem;
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64SegmentPageSizes *sps = slb->sps;
|
2016-01-27 03:52:57 +03:00
|
|
|
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* The SLB store path should prevent any bad page size encodings
|
|
|
|
* getting in there, so:
|
|
|
|
*/
|
2016-07-04 10:44:11 +03:00
|
|
|
assert(sps);
|
2013-03-12 04:31:29 +04:00
|
|
|
|
2016-07-04 10:44:11 +03:00
|
|
|
/* If ISL is set in LPCR we need to clamp the page size to 4K */
|
|
|
|
if (env->spr[SPR_LPCR] & LPCR_ISL) {
|
|
|
|
/* We assume that when using TCG, 4k is first entry of SPS */
|
2018-03-23 05:31:52 +03:00
|
|
|
sps = &cpu->hash64_opts->sps[0];
|
2016-07-04 10:44:11 +03:00
|
|
|
assert(sps->page_shift == 12);
|
|
|
|
}
|
|
|
|
|
|
|
|
epnmask = ~((1ULL << sps->page_shift) - 1);
|
2013-03-12 04:31:29 +04:00
|
|
|
|
|
|
|
if (slb->vsid & SLB_VSID_B) {
|
2013-03-12 04:31:31 +04:00
|
|
|
/* 1TB segment */
|
|
|
|
vsid = (slb->vsid & SLB_VSID_VSID) >> SLB_VSID_SHIFT_1T;
|
|
|
|
epn = (eaddr & ~SEGMENT_MASK_1T) & epnmask;
|
2016-07-04 10:44:11 +03:00
|
|
|
hash = vsid ^ (vsid << 25) ^ (epn >> sps->page_shift);
|
2013-03-12 04:31:29 +04:00
|
|
|
} else {
|
2013-03-12 04:31:31 +04:00
|
|
|
/* 256M segment */
|
|
|
|
vsid = (slb->vsid & SLB_VSID_VSID) >> SLB_VSID_SHIFT;
|
|
|
|
epn = (eaddr & ~SEGMENT_MASK_256M) & epnmask;
|
2016-07-04 10:44:11 +03:00
|
|
|
hash = vsid ^ (epn >> sps->page_shift);
|
2013-03-12 04:31:29 +04:00
|
|
|
}
|
2013-03-12 04:31:31 +04:00
|
|
|
ptem = (slb->vsid & SLB_VSID_PTEM) | ((epn >> 16) & HPTE64_V_AVPN);
|
2016-07-05 05:31:48 +03:00
|
|
|
ptem |= HPTE64_V_VALID;
|
2013-03-12 04:31:29 +04:00
|
|
|
|
|
|
|
/* Page address translation */
|
2014-12-13 19:48:18 +03:00
|
|
|
qemu_log_mask(CPU_LOG_MMU,
|
|
|
|
"htab_base " TARGET_FMT_plx " htab_mask " TARGET_FMT_plx
|
2013-03-12 04:31:29 +04:00
|
|
|
" hash " TARGET_FMT_plx "\n",
|
target/ppc: Eliminate htab_base and htab_mask variables
CPUPPCState includes fields htab_base and htab_mask which store the base
address (GPA) and size (as a mask) of the guest's hashed page table (HPT).
These are set when the SDR1 register is updated.
Keeping these in sync with the SDR1 is actually a little bit fiddly, and
probably not useful for performance, since keeping them expands the size of
CPUPPCState. It also makes some upcoming changes harder to implement.
This patch removes these fields, in favour of calculating them directly
from the SDR1 contents when necessary.
This does make a change to the behaviour of attempting to write a bad value
(invalid HPT size) to the SDR1 with an mtspr instruction. Previously, the
bad value would be stored in SDR1 and could be retrieved with a later
mfspr, but the HPT size as used by the softmmu would be, clamped to the
allowed values. Now, writing a bad value is treated as a no-op. An error
message is printed in both new and old versions.
I'm not sure which behaviour, if either, matches real hardware. I don't
think it matters that much, since it's pretty clear that if an OS writes
a bad value to SDR1, it's not going to boot.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-02-24 08:36:44 +03:00
|
|
|
ppc_hash64_hpt_base(cpu), ppc_hash64_hpt_mask(cpu), hash);
|
2013-03-12 04:31:29 +04:00
|
|
|
|
|
|
|
/* Primary PTEG lookup */
|
2014-12-13 19:48:18 +03:00
|
|
|
qemu_log_mask(CPU_LOG_MMU,
|
|
|
|
"0 htab=" TARGET_FMT_plx "/" TARGET_FMT_plx
|
2013-03-12 04:31:29 +04:00
|
|
|
" vsid=" TARGET_FMT_lx " ptem=" TARGET_FMT_lx
|
|
|
|
" hash=" TARGET_FMT_plx "\n",
|
target/ppc: Eliminate htab_base and htab_mask variables
CPUPPCState includes fields htab_base and htab_mask which store the base
address (GPA) and size (as a mask) of the guest's hashed page table (HPT).
These are set when the SDR1 register is updated.
Keeping these in sync with the SDR1 is actually a little bit fiddly, and
probably not useful for performance, since keeping them expands the size of
CPUPPCState. It also makes some upcoming changes harder to implement.
This patch removes these fields, in favour of calculating them directly
from the SDR1 contents when necessary.
This does make a change to the behaviour of attempting to write a bad value
(invalid HPT size) to the SDR1 with an mtspr instruction. Previously, the
bad value would be stored in SDR1 and could be retrieved with a later
mfspr, but the HPT size as used by the softmmu would be, clamped to the
allowed values. Now, writing a bad value is treated as a no-op. An error
message is printed in both new and old versions.
I'm not sure which behaviour, if either, matches real hardware. I don't
think it matters that much, since it's pretty clear that if an OS writes
a bad value to SDR1, it's not going to boot.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-02-24 08:36:44 +03:00
|
|
|
ppc_hash64_hpt_base(cpu), ppc_hash64_hpt_mask(cpu),
|
|
|
|
vsid, ptem, hash);
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
ptex = ppc_hash64_pteg_search(cpu, hash, sps, ptem, pte, pshift);
|
2013-03-12 04:31:30 +04:00
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
if (ptex == -1) {
|
2013-03-12 04:31:29 +04:00
|
|
|
/* Secondary PTEG lookup */
|
2016-07-05 05:31:48 +03:00
|
|
|
ptem |= HPTE64_V_SECONDARY;
|
2014-12-13 19:48:18 +03:00
|
|
|
qemu_log_mask(CPU_LOG_MMU,
|
|
|
|
"1 htab=" TARGET_FMT_plx "/" TARGET_FMT_plx
|
2013-03-12 04:31:29 +04:00
|
|
|
" vsid=" TARGET_FMT_lx " api=" TARGET_FMT_lx
|
target/ppc: Eliminate htab_base and htab_mask variables
CPUPPCState includes fields htab_base and htab_mask which store the base
address (GPA) and size (as a mask) of the guest's hashed page table (HPT).
These are set when the SDR1 register is updated.
Keeping these in sync with the SDR1 is actually a little bit fiddly, and
probably not useful for performance, since keeping them expands the size of
CPUPPCState. It also makes some upcoming changes harder to implement.
This patch removes these fields, in favour of calculating them directly
from the SDR1 contents when necessary.
This does make a change to the behaviour of attempting to write a bad value
(invalid HPT size) to the SDR1 with an mtspr instruction. Previously, the
bad value would be stored in SDR1 and could be retrieved with a later
mfspr, but the HPT size as used by the softmmu would be, clamped to the
allowed values. Now, writing a bad value is treated as a no-op. An error
message is printed in both new and old versions.
I'm not sure which behaviour, if either, matches real hardware. I don't
think it matters that much, since it's pretty clear that if an OS writes
a bad value to SDR1, it's not going to boot.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-02-24 08:36:44 +03:00
|
|
|
" hash=" TARGET_FMT_plx "\n", ppc_hash64_hpt_base(cpu),
|
|
|
|
ppc_hash64_hpt_mask(cpu), vsid, ptem, ~hash);
|
2013-03-12 04:31:29 +04:00
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
ptex = ppc_hash64_pteg_search(cpu, ~hash, sps, ptem, pte, pshift);
|
2013-03-12 04:31:29 +04:00
|
|
|
}
|
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
return ptex;
|
2013-03-12 04:31:08 +04:00
|
|
|
}
|
2013-03-12 04:31:09 +04:00
|
|
|
|
2016-01-27 04:01:20 +03:00
|
|
|
unsigned ppc_hash64_hpte_page_shift_noslb(PowerPCCPU *cpu,
|
2016-07-01 10:10:10 +03:00
|
|
|
uint64_t pte0, uint64_t pte1)
|
2016-01-27 04:01:20 +03:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!(pte0 & HPTE64_V_LARGE)) {
|
|
|
|
return 12;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The encodings in env->sps need to be carefully chosen so that
|
|
|
|
* this gives an unambiguous result.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < PPC_PAGE_SIZES_MAX_SZ; i++) {
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64SegmentPageSizes *sps = &cpu->hash64_opts->sps[i];
|
2016-01-27 04:01:20 +03:00
|
|
|
unsigned shift;
|
|
|
|
|
|
|
|
if (!sps->page_shift) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
shift = hpte_page_shift(sps, pte0, pte1);
|
|
|
|
if (shift) {
|
|
|
|
return shift;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-11 14:33:02 +03:00
|
|
|
static bool ppc_hash64_use_vrma(CPUPPCState *env)
|
|
|
|
{
|
|
|
|
switch (env->mmu_model) {
|
|
|
|
case POWERPC_MMU_3_00:
|
|
|
|
/*
|
|
|
|
* ISAv3.0 (POWER9) always uses VRMA, the VPM0 field and RMOR
|
|
|
|
* register no longer exist
|
|
|
|
*/
|
|
|
|
return true;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return !!(env->spr[SPR_LPCR] & LPCR_VPM0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-22 08:49:28 +03:00
|
|
|
static void ppc_hash64_set_isi(CPUState *cs, uint64_t error_code)
|
2016-06-22 00:48:50 +03:00
|
|
|
{
|
2018-03-22 08:49:28 +03:00
|
|
|
CPUPPCState *env = &POWERPC_CPU(cs)->env;
|
2016-06-22 00:48:50 +03:00
|
|
|
bool vpm;
|
|
|
|
|
|
|
|
if (msr_ir) {
|
|
|
|
vpm = !!(env->spr[SPR_LPCR] & LPCR_VPM1);
|
|
|
|
} else {
|
2019-12-11 14:33:02 +03:00
|
|
|
vpm = ppc_hash64_use_vrma(env);
|
2016-06-22 00:48:50 +03:00
|
|
|
}
|
|
|
|
if (vpm && !msr_hv) {
|
|
|
|
cs->exception_index = POWERPC_EXCP_HISI;
|
|
|
|
} else {
|
|
|
|
cs->exception_index = POWERPC_EXCP_ISI;
|
|
|
|
}
|
|
|
|
env->error_code = error_code;
|
|
|
|
}
|
|
|
|
|
2018-03-22 08:49:28 +03:00
|
|
|
static void ppc_hash64_set_dsi(CPUState *cs, uint64_t dar, uint64_t dsisr)
|
2016-06-22 00:48:50 +03:00
|
|
|
{
|
2018-03-22 08:49:28 +03:00
|
|
|
CPUPPCState *env = &POWERPC_CPU(cs)->env;
|
2016-06-22 00:48:50 +03:00
|
|
|
bool vpm;
|
|
|
|
|
|
|
|
if (msr_dr) {
|
|
|
|
vpm = !!(env->spr[SPR_LPCR] & LPCR_VPM1);
|
|
|
|
} else {
|
2019-12-11 14:33:02 +03:00
|
|
|
vpm = ppc_hash64_use_vrma(env);
|
2016-06-22 00:48:50 +03:00
|
|
|
}
|
|
|
|
if (vpm && !msr_hv) {
|
|
|
|
cs->exception_index = POWERPC_EXCP_HDSI;
|
|
|
|
env->spr[SPR_HDAR] = dar;
|
|
|
|
env->spr[SPR_HDSISR] = dsisr;
|
|
|
|
} else {
|
|
|
|
cs->exception_index = POWERPC_EXCP_DSI;
|
|
|
|
env->spr[SPR_DAR] = dar;
|
|
|
|
env->spr[SPR_DSISR] = dsisr;
|
|
|
|
}
|
|
|
|
env->error_code = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-04-11 11:00:01 +03:00
|
|
|
static void ppc_hash64_set_r(PowerPCCPU *cpu, hwaddr ptex, uint64_t pte1)
|
|
|
|
{
|
|
|
|
hwaddr base, offset = ptex * HASH_PTE_SIZE_64 + 16;
|
|
|
|
|
|
|
|
if (cpu->vhyp) {
|
|
|
|
PPCVirtualHypervisorClass *vhc =
|
|
|
|
PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
|
|
|
|
vhc->hpte_set_r(cpu->vhyp, ptex, pte1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
base = ppc_hash64_hpt_base(cpu);
|
|
|
|
|
|
|
|
|
|
|
|
/* The HW performs a non-atomic byte update */
|
|
|
|
stb_phys(CPU(cpu)->as, base + offset, ((pte1 >> 8) & 0xff) | 0x01);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ppc_hash64_set_c(PowerPCCPU *cpu, hwaddr ptex, uint64_t pte1)
|
|
|
|
{
|
|
|
|
hwaddr base, offset = ptex * HASH_PTE_SIZE_64 + 15;
|
|
|
|
|
|
|
|
if (cpu->vhyp) {
|
|
|
|
PPCVirtualHypervisorClass *vhc =
|
|
|
|
PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
|
|
|
|
vhc->hpte_set_c(cpu->vhyp, ptex, pte1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
base = ppc_hash64_hpt_base(cpu);
|
|
|
|
|
|
|
|
/* The HW performs a non-atomic byte update */
|
|
|
|
stb_phys(CPU(cpu)->as, base + offset, (pte1 & 0xff) | 0x80);
|
|
|
|
}
|
|
|
|
|
2020-01-06 08:52:26 +03:00
|
|
|
static target_ulong rmls_limit(PowerPCCPU *cpu)
|
|
|
|
{
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
/*
|
2020-01-06 09:18:54 +03:00
|
|
|
* In theory the meanings of RMLS values are implementation
|
|
|
|
* dependent. In practice, this seems to have been the set from
|
|
|
|
* POWER4+..POWER8, and RMLS is no longer supported in POWER9.
|
2020-01-06 08:52:26 +03:00
|
|
|
*
|
|
|
|
* Unsupported values mean the OS has shot itself in the
|
|
|
|
* foot. Return a 0-sized RMA in this case, which we expect
|
|
|
|
* to trigger an immediate DSI or ISI
|
|
|
|
*/
|
|
|
|
static const target_ulong rma_sizes[16] = {
|
2020-01-06 09:18:54 +03:00
|
|
|
[0] = 256 * GiB,
|
2020-01-06 08:52:26 +03:00
|
|
|
[1] = 16 * GiB,
|
|
|
|
[2] = 1 * GiB,
|
|
|
|
[3] = 64 * MiB,
|
|
|
|
[4] = 256 * MiB,
|
|
|
|
[7] = 128 * MiB,
|
|
|
|
[8] = 32 * MiB,
|
|
|
|
};
|
|
|
|
target_ulong rmls = (env->spr[SPR_LPCR] & LPCR_RMLS) >> LPCR_RMLS_SHIFT;
|
|
|
|
|
|
|
|
return rma_sizes[rmls];
|
|
|
|
}
|
|
|
|
|
2020-02-27 07:29:26 +03:00
|
|
|
static int build_vrma_slbe(PowerPCCPU *cpu, ppc_slb_t *slb)
|
|
|
|
{
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
target_ulong lpcr = env->spr[SPR_LPCR];
|
|
|
|
uint32_t vrmasd = (lpcr & LPCR_VRMASD) >> LPCR_VRMASD_SHIFT;
|
|
|
|
target_ulong vsid = SLB_VSID_VRMA | ((vrmasd << 4) & SLB_VSID_LLP_MASK);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < PPC_PAGE_SIZES_MAX_SZ; i++) {
|
|
|
|
const PPCHash64SegmentPageSizes *sps = &cpu->hash64_opts->sps[i];
|
|
|
|
|
|
|
|
if (!sps->page_shift) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((vsid & SLB_VSID_LLP_MASK) == sps->slb_enc) {
|
|
|
|
slb->esid = SLB_ESID_V;
|
|
|
|
slb->vsid = vsid;
|
|
|
|
slb->sps = sps;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
error_report("Bad page size encoding in LPCR[VRMASD]; LPCR=0x"
|
2020-07-22 11:40:46 +03:00
|
|
|
TARGET_FMT_lx, lpcr);
|
2020-02-27 07:29:26 +03:00
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-03-15 17:12:16 +03:00
|
|
|
int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr eaddr,
|
2013-03-12 04:31:46 +04:00
|
|
|
int rwx, int mmu_idx)
|
2013-03-12 04:31:09 +04:00
|
|
|
{
|
2013-09-02 16:14:24 +04:00
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
2020-02-27 07:29:26 +03:00
|
|
|
ppc_slb_t vrma_slbe;
|
2013-03-12 04:31:09 +04:00
|
|
|
ppc_slb_t *slb;
|
2016-01-27 03:39:15 +03:00
|
|
|
unsigned apshift;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
hwaddr ptex;
|
2013-03-12 04:31:30 +04:00
|
|
|
ppc_hash_pte64_t pte;
|
2017-03-01 10:12:54 +03:00
|
|
|
int exec_prot, pp_prot, amr_prot, prot;
|
2013-03-12 04:31:40 +04:00
|
|
|
const int need_prot[] = {PAGE_READ, PAGE_WRITE, PAGE_EXEC};
|
2013-03-12 04:31:46 +04:00
|
|
|
hwaddr raddr;
|
2013-03-12 04:31:09 +04:00
|
|
|
|
2013-03-12 04:31:32 +04:00
|
|
|
assert((rwx == 0) || (rwx == 1) || (rwx == 2));
|
|
|
|
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* Note on LPCR usage: 970 uses HID4, but our special variant of
|
|
|
|
* store_spr copies relevant fields into env->spr[SPR_LPCR].
|
2020-10-09 09:44:37 +03:00
|
|
|
* Similarly we filter unimplemented bits when storing into LPCR
|
2019-03-21 14:32:53 +03:00
|
|
|
* depending on the MMU version. This code can thus just use the
|
|
|
|
* LPCR "as-is".
|
2016-07-05 00:37:08 +03:00
|
|
|
*/
|
|
|
|
|
2013-03-12 04:31:23 +04:00
|
|
|
/* 1. Handle real mode accesses */
|
|
|
|
if (((rwx == 2) && (msr_ir == 0)) || ((rwx != 2) && (msr_dr == 0))) {
|
2019-03-21 14:32:53 +03:00
|
|
|
/*
|
|
|
|
* Translation is supposedly "off", but in real mode the top 4
|
|
|
|
* effective address bits are (mostly) ignored
|
|
|
|
*/
|
2013-03-12 04:31:46 +04:00
|
|
|
raddr = eaddr & 0x0FFFFFFFFFFFFFFFULL;
|
2016-07-05 00:37:08 +03:00
|
|
|
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
if (cpu->vhyp) {
|
|
|
|
/*
|
|
|
|
* In virtual hypervisor mode, there's nothing to do:
|
|
|
|
* EA == GPA == qemu guest address
|
|
|
|
*/
|
|
|
|
} else if (msr_hv || !env->has_hv_mode) {
|
|
|
|
/* In HV mode, add HRMOR if top EA bit is clear */
|
2016-07-05 00:37:08 +03:00
|
|
|
if (!(eaddr >> 63)) {
|
|
|
|
raddr |= env->spr[SPR_HRMOR];
|
|
|
|
}
|
2019-12-11 14:33:02 +03:00
|
|
|
} else if (ppc_hash64_use_vrma(env)) {
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
/* Emulated VRMA mode */
|
2020-02-27 07:29:26 +03:00
|
|
|
slb = &vrma_slbe;
|
|
|
|
if (build_vrma_slbe(cpu, slb) != 0) {
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
/* Invalid VRMA setup, machine check */
|
2016-07-05 00:37:08 +03:00
|
|
|
cs->exception_index = POWERPC_EXCP_MCHECK;
|
|
|
|
env->error_code = 0;
|
|
|
|
return 1;
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
goto skip_slb_search;
|
|
|
|
} else {
|
2020-01-06 09:26:24 +03:00
|
|
|
target_ulong limit = rmls_limit(cpu);
|
|
|
|
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
/* Emulated old-style RMO mode, bounds check against RMLS */
|
2020-01-06 09:26:24 +03:00
|
|
|
if (raddr >= limit) {
|
2016-07-05 00:37:08 +03:00
|
|
|
if (rwx == 2) {
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_isi(cs, SRR1_PROTFAULT);
|
2016-07-05 00:37:08 +03:00
|
|
|
} else {
|
2017-03-01 10:12:55 +03:00
|
|
|
int dsisr = DSISR_PROTFAULT;
|
2016-07-05 00:37:08 +03:00
|
|
|
if (rwx == 1) {
|
2017-03-01 10:12:55 +03:00
|
|
|
dsisr |= DSISR_ISSTORE;
|
2016-07-05 00:37:08 +03:00
|
|
|
}
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_dsi(cs, eaddr, dsisr);
|
2016-07-05 00:37:08 +03:00
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
|
|
|
|
raddr |= env->spr[SPR_RMOR];
|
2016-07-05 00:37:08 +03:00
|
|
|
}
|
2013-09-03 15:59:37 +04:00
|
|
|
tlb_set_page(cs, eaddr & TARGET_PAGE_MASK, raddr & TARGET_PAGE_MASK,
|
2013-03-12 04:31:46 +04:00
|
|
|
PAGE_READ | PAGE_WRITE | PAGE_EXEC, mmu_idx,
|
|
|
|
TARGET_PAGE_SIZE);
|
2013-03-12 04:31:23 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-12 04:31:26 +04:00
|
|
|
/* 2. Translation is on, so look up the SLB */
|
2016-01-14 07:33:27 +03:00
|
|
|
slb = slb_lookup(cpu, eaddr);
|
2013-03-12 04:31:09 +04:00
|
|
|
if (!slb) {
|
2017-03-01 09:54:38 +03:00
|
|
|
/* No entry found, check if in-memory segment tables are in use */
|
2018-03-23 08:42:45 +03:00
|
|
|
if (ppc64_use_proc_tbl(cpu)) {
|
2017-03-01 09:54:38 +03:00
|
|
|
/* TODO - Unsupported */
|
|
|
|
error_report("Segment Table Support Unimplemented");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
/* Segment still not found, generate the appropriate interrupt */
|
2013-03-12 04:31:46 +04:00
|
|
|
if (rwx == 2) {
|
2013-08-26 10:31:06 +04:00
|
|
|
cs->exception_index = POWERPC_EXCP_ISEG;
|
2013-03-12 04:31:46 +04:00
|
|
|
env->error_code = 0;
|
|
|
|
} else {
|
2013-08-26 10:31:06 +04:00
|
|
|
cs->exception_index = POWERPC_EXCP_DSEG;
|
2013-03-12 04:31:46 +04:00
|
|
|
env->error_code = 0;
|
|
|
|
env->spr[SPR_DAR] = eaddr;
|
|
|
|
}
|
|
|
|
return 1;
|
2013-03-12 04:31:09 +04:00
|
|
|
}
|
|
|
|
|
2016-07-05 00:37:08 +03:00
|
|
|
skip_slb_search:
|
|
|
|
|
2013-03-12 04:31:26 +04:00
|
|
|
/* 3. Check for segment level no-execute violation */
|
|
|
|
if ((rwx == 2) && (slb->vsid & SLB_VSID_N)) {
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_isi(cs, SRR1_NOEXEC_GUARD);
|
2013-03-12 04:31:46 +04:00
|
|
|
return 1;
|
2013-03-12 04:31:26 +04:00
|
|
|
}
|
|
|
|
|
2013-03-12 04:31:30 +04:00
|
|
|
/* 4. Locate the PTE in the hash table */
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
ptex = ppc_hash64_htab_lookup(cpu, slb, eaddr, &pte, &apshift);
|
|
|
|
if (ptex == -1) {
|
2013-03-12 04:31:46 +04:00
|
|
|
if (rwx == 2) {
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_isi(cs, SRR1_NOPTE);
|
2013-03-12 04:31:46 +04:00
|
|
|
} else {
|
2017-03-01 10:12:55 +03:00
|
|
|
int dsisr = DSISR_NOPTE;
|
2013-03-12 04:31:46 +04:00
|
|
|
if (rwx == 1) {
|
2017-03-01 10:12:55 +03:00
|
|
|
dsisr |= DSISR_ISSTORE;
|
2013-03-12 04:31:46 +04:00
|
|
|
}
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_dsi(cs, eaddr, dsisr);
|
2013-03-12 04:31:46 +04:00
|
|
|
}
|
|
|
|
return 1;
|
2013-03-12 04:31:30 +04:00
|
|
|
}
|
2014-12-13 19:48:18 +03:00
|
|
|
qemu_log_mask(CPU_LOG_MMU,
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
"found PTE at index %08" HWADDR_PRIx "\n", ptex);
|
2013-03-12 04:31:30 +04:00
|
|
|
|
|
|
|
/* 5. Check access permissions */
|
|
|
|
|
2017-03-01 10:12:54 +03:00
|
|
|
exec_prot = ppc_hash64_pte_noexec_guard(cpu, pte);
|
2016-01-14 07:33:27 +03:00
|
|
|
pp_prot = ppc_hash64_pte_prot(cpu, slb, pte);
|
|
|
|
amr_prot = ppc_hash64_amr_prot(cpu, pte);
|
2017-03-01 10:12:54 +03:00
|
|
|
prot = exec_prot & pp_prot & amr_prot;
|
2013-03-12 04:31:32 +04:00
|
|
|
|
2013-03-12 04:31:46 +04:00
|
|
|
if ((need_prot[rwx] & ~prot) != 0) {
|
2013-03-12 04:31:32 +04:00
|
|
|
/* Access right violation */
|
2014-12-13 19:48:18 +03:00
|
|
|
qemu_log_mask(CPU_LOG_MMU, "PTE access rejected\n");
|
2013-03-12 04:31:46 +04:00
|
|
|
if (rwx == 2) {
|
2017-03-01 10:12:52 +03:00
|
|
|
int srr1 = 0;
|
2017-03-01 10:12:54 +03:00
|
|
|
if (PAGE_EXEC & ~exec_prot) {
|
|
|
|
srr1 |= SRR1_NOEXEC_GUARD; /* Access violates noexec or guard */
|
|
|
|
} else if (PAGE_EXEC & ~pp_prot) {
|
2017-03-01 10:12:52 +03:00
|
|
|
srr1 |= SRR1_PROTFAULT; /* Access violates access authority */
|
|
|
|
}
|
|
|
|
if (PAGE_EXEC & ~amr_prot) {
|
|
|
|
srr1 |= SRR1_IAMR; /* Access violates virt pg class key prot */
|
|
|
|
}
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_isi(cs, srr1);
|
2013-03-12 04:31:46 +04:00
|
|
|
} else {
|
2017-03-01 10:12:55 +03:00
|
|
|
int dsisr = 0;
|
2013-03-12 04:31:47 +04:00
|
|
|
if (need_prot[rwx] & ~pp_prot) {
|
2017-03-01 10:12:55 +03:00
|
|
|
dsisr |= DSISR_PROTFAULT;
|
2013-03-12 04:31:47 +04:00
|
|
|
}
|
2013-03-12 04:31:46 +04:00
|
|
|
if (rwx == 1) {
|
2017-03-01 10:12:55 +03:00
|
|
|
dsisr |= DSISR_ISSTORE;
|
2013-03-12 04:31:47 +04:00
|
|
|
}
|
|
|
|
if (need_prot[rwx] & ~amr_prot) {
|
2017-03-01 10:12:55 +03:00
|
|
|
dsisr |= DSISR_AMR;
|
2013-03-12 04:31:46 +04:00
|
|
|
}
|
2018-03-22 08:49:28 +03:00
|
|
|
ppc_hash64_set_dsi(cs, eaddr, dsisr);
|
2013-03-12 04:31:46 +04:00
|
|
|
}
|
|
|
|
return 1;
|
2013-03-12 04:31:32 +04:00
|
|
|
}
|
|
|
|
|
2014-12-13 19:48:18 +03:00
|
|
|
qemu_log_mask(CPU_LOG_MMU, "PTE access granted !\n");
|
2013-03-12 04:31:38 +04:00
|
|
|
|
|
|
|
/* 6. Update PTE referenced and changed bits if necessary */
|
|
|
|
|
2019-04-11 11:00:01 +03:00
|
|
|
if (!(pte.pte1 & HPTE64_R_R)) {
|
|
|
|
ppc_hash64_set_r(cpu, ptex, pte.pte1);
|
2013-03-12 04:31:42 +04:00
|
|
|
}
|
2019-04-11 11:00:01 +03:00
|
|
|
if (!(pte.pte1 & HPTE64_R_C)) {
|
|
|
|
if (rwx == 1) {
|
|
|
|
ppc_hash64_set_c(cpu, ptex, pte.pte1);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Treat the page as read-only for now, so that a later write
|
|
|
|
* will pass through this function again to set the C bit
|
|
|
|
*/
|
|
|
|
prot &= ~PAGE_WRITE;
|
|
|
|
}
|
2013-03-12 04:31:30 +04:00
|
|
|
}
|
2013-03-12 04:31:09 +04:00
|
|
|
|
2013-03-12 04:31:43 +04:00
|
|
|
/* 7. Determine the real address from the PTE */
|
|
|
|
|
2016-01-27 03:39:15 +03:00
|
|
|
raddr = deposit64(pte.pte1 & HPTE64_R_RPN, 0, apshift, eaddr);
|
2013-03-12 04:31:46 +04:00
|
|
|
|
2013-09-03 15:59:37 +04:00
|
|
|
tlb_set_page(cs, eaddr & TARGET_PAGE_MASK, raddr & TARGET_PAGE_MASK,
|
2016-01-27 03:39:15 +03:00
|
|
|
prot, mmu_idx, 1ULL << apshift);
|
2013-03-12 04:31:40 +04:00
|
|
|
|
|
|
|
return 0;
|
2013-03-12 04:31:09 +04:00
|
|
|
}
|
2013-03-12 04:31:11 +04:00
|
|
|
|
2016-01-14 07:33:27 +03:00
|
|
|
hwaddr ppc_hash64_get_phys_page_debug(PowerPCCPU *cpu, target_ulong addr)
|
2013-03-12 04:31:13 +04:00
|
|
|
{
|
2016-01-14 07:33:27 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2020-02-27 07:29:26 +03:00
|
|
|
ppc_slb_t vrma_slbe;
|
2013-03-12 04:31:45 +04:00
|
|
|
ppc_slb_t *slb;
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
hwaddr ptex, raddr;
|
2013-03-12 04:31:45 +04:00
|
|
|
ppc_hash_pte64_t pte;
|
2016-01-27 03:39:15 +03:00
|
|
|
unsigned apshift;
|
2013-03-12 04:31:45 +04:00
|
|
|
|
2016-07-05 00:37:08 +03:00
|
|
|
/* Handle real mode */
|
2013-03-12 04:31:45 +04:00
|
|
|
if (msr_dr == 0) {
|
|
|
|
/* In real mode the top 4 effective address bits are ignored */
|
2016-07-05 00:37:08 +03:00
|
|
|
raddr = addr & 0x0FFFFFFFFFFFFFFFULL;
|
2013-03-12 04:31:13 +04:00
|
|
|
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
if (cpu->vhyp) {
|
|
|
|
/*
|
|
|
|
* In virtual hypervisor mode, there's nothing to do:
|
|
|
|
* EA == GPA == qemu guest address
|
|
|
|
*/
|
|
|
|
return raddr;
|
|
|
|
} else if ((msr_hv || !env->has_hv_mode) && !(addr >> 63)) {
|
|
|
|
/* In HV mode, add HRMOR if top EA bit is clear */
|
2016-07-05 00:37:08 +03:00
|
|
|
return raddr | env->spr[SPR_HRMOR];
|
2019-12-11 14:33:02 +03:00
|
|
|
} else if (ppc_hash64_use_vrma(env)) {
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
/* Emulated VRMA mode */
|
2020-02-27 07:29:26 +03:00
|
|
|
slb = &vrma_slbe;
|
|
|
|
if (build_vrma_slbe(cpu, slb) != 0) {
|
2016-07-05 00:37:08 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
2020-01-06 09:26:24 +03:00
|
|
|
target_ulong limit = rmls_limit(cpu);
|
|
|
|
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
/* Emulated old-style RMO mode, bounds check against RMLS */
|
2020-01-06 09:26:24 +03:00
|
|
|
if (raddr >= limit) {
|
target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-01-03 07:27:24 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return raddr | env->spr[SPR_RMOR];
|
2016-07-05 00:37:08 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
slb = slb_lookup(cpu, addr);
|
|
|
|
if (!slb) {
|
|
|
|
return -1;
|
|
|
|
}
|
2013-03-12 04:31:45 +04:00
|
|
|
}
|
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
ptex = ppc_hash64_htab_lookup(cpu, slb, addr, &pte, &apshift);
|
|
|
|
if (ptex == -1) {
|
2013-03-12 04:31:13 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-01-27 03:39:15 +03:00
|
|
|
return deposit64(pte.pte1 & HPTE64_R_RPN, 0, apshift, addr)
|
2016-01-27 03:52:57 +03:00
|
|
|
& TARGET_PAGE_MASK;
|
2013-03-12 04:31:13 +04:00
|
|
|
}
|
2014-02-20 21:52:38 +04:00
|
|
|
|
target/ppc: Cleanup HPTE accessors for 64-bit hash MMU
Accesses to the hashed page table (HPT) are complicated by the fact that
the HPT could be in one of three places:
1) Within guest memory - when we're emulating a full guest CPU at the
hardware level (e.g. powernv, mac99, g3beige)
2) Within qemu, but outside guest memory - when we're emulating user and
supervisor instructions within TCG, but instead of emulating
the CPU's hypervisor mode, we just emulate a hypervisor's behaviour
(pseries in TCG or KVM-PR)
3) Within the host kernel - a pseries machine using KVM-HV
acceleration. Mostly accesses to the HPT are handled by KVM,
but there are a few cases where qemu needs to access it via a
special fd for the purpose.
In order to batch accesses to the fd in case (3), we use a somewhat awkward
ppc_hash64_start_access() / ppc_hash64_stop_access() pair, which for case
(3) reads / releases several HPTEs from the kernel as a batch (usually a
whole PTEG). For cases (1) & (2) it just returns an address value. The
actual HPTE load helpers then need to interpret the returned token
differently in the 3 cases.
This patch keeps the same basic structure, but simplfiies the details.
First start_access() / stop_access() are renamed to map_hptes() and
unmap_hptes() to make their operation more obvious. Second, map_hptes()
now always returns a qemu pointer, which can always be used in the same way
by the load_hpte() helpers. In case (1) it comes from address_space_map()
in case (2) directly from qemu's HPT buffer and in case (3) from a
temporary buffer read from the KVM fd.
While we're at it, make things a bit more consistent in terms of types and
variable names: avoid variables named 'index' (it shadows index(3) which
can lead to confusing results), use 'hwaddr ptex' for HPTE indices and
uint64_t for each of the HPTE words, use ptex throughout the call stack
instead of pte_offset in some places (we still need that at the bottom
layer, but nowhere else).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-27 08:03:41 +03:00
|
|
|
void ppc_hash64_tlb_flush_hpte(PowerPCCPU *cpu, target_ulong ptex,
|
2016-01-15 08:12:09 +03:00
|
|
|
target_ulong pte0, target_ulong pte1)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* XXX: given the fact that there are too many segments to
|
|
|
|
* invalidate, and we still don't have a tlb_flush_mask(env, n,
|
|
|
|
* mask) in QEMU, we just invalidate all TLBs
|
|
|
|
*/
|
2016-09-20 19:35:01 +03:00
|
|
|
cpu->env.tlb_need_flush = TLB_NEED_GLOBAL_FLUSH | TLB_NEED_LOCAL_FLUSH;
|
2016-01-15 08:12:09 +03:00
|
|
|
}
|
2016-06-27 09:55:16 +03:00
|
|
|
|
2018-04-05 09:43:59 +03:00
|
|
|
void helper_store_lpcr(CPUPPCState *env, target_ulong val)
|
|
|
|
{
|
2019-03-23 05:07:57 +03:00
|
|
|
PowerPCCPU *cpu = env_archcpu(env);
|
2018-04-05 09:43:59 +03:00
|
|
|
|
|
|
|
ppc_store_lpcr(cpu, val);
|
|
|
|
}
|
|
|
|
|
2018-03-23 05:07:48 +03:00
|
|
|
void ppc_hash64_init(PowerPCCPU *cpu)
|
|
|
|
{
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
|
|
|
|
|
2018-03-23 05:59:20 +03:00
|
|
|
if (!pcc->hash64_opts) {
|
2020-12-09 20:35:36 +03:00
|
|
|
assert(!mmu_is_64bit(env->mmu_model));
|
2018-03-23 05:59:20 +03:00
|
|
|
return;
|
2018-03-23 05:07:48 +03:00
|
|
|
}
|
2018-03-23 05:59:20 +03:00
|
|
|
|
|
|
|
cpu->hash64_opts = g_memdup(pcc->hash64_opts, sizeof(*cpu->hash64_opts));
|
2018-03-23 05:07:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void ppc_hash64_finalize(PowerPCCPU *cpu)
|
|
|
|
{
|
2018-03-23 05:31:52 +03:00
|
|
|
g_free(cpu->hash64_opts);
|
2018-03-23 05:07:48 +03:00
|
|
|
}
|
2018-03-23 05:31:52 +03:00
|
|
|
|
2018-03-23 05:59:20 +03:00
|
|
|
const PPCHash64Options ppc_hash64_opts_basic = {
|
2018-03-23 06:11:07 +03:00
|
|
|
.flags = 0,
|
2018-03-29 10:29:38 +03:00
|
|
|
.slb_size = 64,
|
2018-03-23 05:59:20 +03:00
|
|
|
.sps = {
|
|
|
|
{ .page_shift = 12, /* 4K */
|
|
|
|
.slb_enc = 0,
|
|
|
|
.enc = { { .page_shift = 12, .pte_enc = 0 } }
|
|
|
|
},
|
|
|
|
{ .page_shift = 24, /* 16M */
|
|
|
|
.slb_enc = 0x100,
|
|
|
|
.enc = { { .page_shift = 24, .pte_enc = 0 } }
|
|
|
|
},
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2018-03-23 05:31:52 +03:00
|
|
|
const PPCHash64Options ppc_hash64_opts_POWER7 = {
|
2018-03-23 06:32:48 +03:00
|
|
|
.flags = PPC_HASH64_1TSEG | PPC_HASH64_AMR | PPC_HASH64_CI_LARGEPAGE,
|
2018-03-29 10:29:38 +03:00
|
|
|
.slb_size = 32,
|
2018-03-23 05:31:52 +03:00
|
|
|
.sps = {
|
|
|
|
{
|
|
|
|
.page_shift = 12, /* 4K */
|
|
|
|
.slb_enc = 0,
|
|
|
|
.enc = { { .page_shift = 12, .pte_enc = 0 },
|
|
|
|
{ .page_shift = 16, .pte_enc = 0x7 },
|
|
|
|
{ .page_shift = 24, .pte_enc = 0x38 }, },
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.page_shift = 16, /* 64K */
|
|
|
|
.slb_enc = SLB_VSID_64K,
|
|
|
|
.enc = { { .page_shift = 16, .pte_enc = 0x1 },
|
|
|
|
{ .page_shift = 24, .pte_enc = 0x8 }, },
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.page_shift = 24, /* 16M */
|
|
|
|
.slb_enc = SLB_VSID_16M,
|
|
|
|
.enc = { { .page_shift = 24, .pte_enc = 0 }, },
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.page_shift = 34, /* 16G */
|
|
|
|
.slb_enc = SLB_VSID_16G,
|
|
|
|
.enc = { { .page_shift = 34, .pte_enc = 0x3 }, },
|
|
|
|
},
|
|
|
|
}
|
|
|
|
};
|
2018-03-26 07:01:22 +03:00
|
|
|
|
|
|
|
|