]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
arm: KVM: force execution of HCPTR access on VM exit
authorMarc Zyngier <marc.zyngier@arm.com>
Mon, 16 Mar 2015 10:59:43 +0000 (10:59 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 10 Jul 2015 16:45:40 +0000 (09:45 -0700)
commit13731ac9eaf1b6fd6c6329b3d35923fd2078befb
tree5fa8bf942cd73603009319d6cbaf46ed19e5b256
parentcb5420eb3900929c9dc8dd95de7d8546e38e3708
arm: KVM: force execution of HCPTR access on VM exit

commit 85e84ba31039595995dae80b277378213602891b upstream.

On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.

On VM exit, we restore access, test if we did enable them before,
and save/restore the guest/host registers if necessary. In this
sequence, the FPEXC register is always accessed, irrespective
of the trapping configuration.

If the guest didn't touch the VFP registers, then the HCPTR access
has now enabled such access, but we're missing a barrier to ensure
architectural execution of the new HCPTR configuration. If the HCPTR
access has been delayed/reordered, the subsequent access to FPEXC
will cause a trap, which we aren't prepared to handle at all.

The same condition exists when trapping to enable VFP for the guest.

The fix is to introduce a barrier after enabling VFP access. In the
vmexit case, it can be relaxed to only takes place if the guest hasn't
accessed its view of the VFP registers, making the access to FPEXC safe.

The set_hcptr macro is modified to deal with both vmenter/vmexit and
vmtrap operations, and now takes an optional label that is branched to
when the guest hasn't touched the VFP registers.

Reported-by: Vikram Sethi <vikrams@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arm/kvm/interrupts.S
arch/arm/kvm/interrupts_head.S