aboutsummaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorMarc Zyngier <marc.zyngier@arm.com>2015-03-16 10:59:43 +0000
committerMoyster <oysterized@gmail.com>2016-08-26 19:17:24 +0200
commitd94fd57f59f05132c6000bbabd928a03d9a81dc9 (patch)
tree221c4b80f20121bde53eab423d4374a99a8a9e80 /scripts/basic
parentacc86a38f497957e2350b46f8cff615281292cbc (diff)
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> Signed-off-by: Stefan Guendhoer <stefan@guendhoer.com>
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions