summaryrefslogtreecommitdiff
path: root/target/s390x
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2020-01-03 15:27:24 +1100
committerDavid Gibson <david@gibson.dropbear.id.au>2020-03-17 09:41:15 +1100
commit682c1dfb86acb19f542d06375b97c604ee000730 (patch)
treed6ca7806aebde01b8abf7eef60f2d9b600ecc9d7 /target/s390x
parent19acd4b610a2f6a8db2840faecaab813089a33b2 (diff)
downloadqemu-682c1dfb86acb19f542d06375b97c604ee000730.zip
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>
Diffstat (limited to 'target/s390x')
0 files changed, 0 insertions, 0 deletions