diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2020-01-03 15:27:24 +1100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2020-03-17 09:41:15 +1100 |
commit | 682c1dfb86acb19f542d06375b97c604ee000730 (patch) | |
tree | d6ca7806aebde01b8abf7eef60f2d9b600ecc9d7 /crypto | |
parent | 19acd4b610a2f6a8db2840faecaab813089a33b2 (diff) | |
download | qemu-682c1dfb86acb19f542d06375b97c604ee000730.zip qemu-682c1dfb86acb19f542d06375b97c604ee000730.tar.gz qemu-682c1dfb86acb19f542d06375b97c604ee000730.tar.bz2 |
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 'crypto')
0 files changed, 0 insertions, 0 deletions