]> git.proxmox.com Git - mirror_qemu.git/commit
pseries: Enable in-kernel H_LOGICAL_CI_{LOAD, STORE} implementations
authorDavid Gibson <david@gibson.dropbear.id.au>
Thu, 7 May 2015 05:33:59 +0000 (15:33 +1000)
committerAlexander Graf <agraf@suse.de>
Wed, 3 Jun 2015 21:56:55 +0000 (23:56 +0200)
commit026bfd89cb896c8a3460cc551cc4836219bd7ff9
tree0184f5e47dd4b528355f5bdfb9d381b3a760556d
parenta34944fe2e2457309bde74c1ffe3a1c60c6da018
pseries: Enable in-kernel H_LOGICAL_CI_{LOAD, STORE} implementations

qemu currently implements the hypercalls H_LOGICAL_CI_LOAD and
H_LOGICAL_CI_STORE as PAPR extensions.  These are used by the SLOF firmware
for IO, because performing cache inhibited MMIO accesses with the MMU off
(real mode) is very awkward on POWER.

This approach breaks when SLOF needs to access IO devices implemented
within KVM instead of in qemu.  The simplest example would be virtio-blk
using an iothread, because the iothread / dataplane mechanism relies on
an in-kernel implementation of the virtio queue notification MMIO.

To fix this, an in-kernel implementation of these hypercalls has been made,
(kernel commit 99342cf "kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM"
however, the hypercalls still need to be enabled from qemu.  This performs
the necessary calls to do so.

It would be nice to provide some warning if we encounter a problematic
device with a kernel which doesn't support the new calls.  Unfortunately,
I can't see a way to detect this case which won't either warn in far too
many cases that will probably work, or which is horribly invasive.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
hw/ppc/spapr.c
target-ppc/kvm.c
target-ppc/kvm_ppc.h