spapr: Don't rewrite mmu capabilities in KVM mode
commite5ca28ecab5c69b7578e22391a66c97c3979ffd8
authorDavid Gibson <david@gibson.dropbear.id.au>
Mon, 16 Apr 2018 06:19:52 +0000 (16 16:19 +1000)
committerDavid Gibson <david@gibson.dropbear.id.au>
Fri, 22 Jun 2018 04:19:07 +0000 (22 14:19 +1000)
treee5977c3e73c0f848d8d7b93543d18f44731ed96f
parent9dceda5fc34a5868012260ee7271c7a6f36cc1f4
spapr: Don't rewrite mmu capabilities in KVM mode

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

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

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

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

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

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
hw/ppc/spapr_cpu_core.c
target/ppc/kvm.c
target/ppc/kvm_ppc.h