On 15.03.16 06:51, Alexey Kardashevskiy wrote:
ePAPR defines "hcall-instructions" device-tree property which contains
code to call hypercalls in ePAPR paravirtualized guests. However this
property is also present for pseries guests where it does not make sense,
even though it contains dummy code which simply fails.
Instead of maintaining the property (which used to be BE only; then was
fixed to be endian-agnostic) and confusing the guest (which might think
there is ePAPR host while there is none), this simply does not
the property to the device tree if the host kernel does not implement it.
In order to tell the machine code if the host kernel supports
KVM_CAP_PPC_GET_PVINFO, this changes kvmppc_get_hypercall() to return 1
if the host kernel does not implement it (which is HV KVM case).
Signed-off-by: Alexey Kardashevskiy <address@hidden>
---
Alexander,
We just got a bug report that LE guests would not boot under quite old QEMU
and we (powerkvm) wonder if it makes sense to backport endian-agnostic
hypercall code to older QEMU or it is simpler/more correct
not to have epapr-hypercall property in the tree.
Without the property you lose KVM hypercalls, so mostly some PR
speedups.
For HV KVM, I don't think it makes a lot of sense to expose
KVM specific hypercalls, but I'm not sure it's a great idea to block the
path. With the infrastructure in place, we can at least add non-sPAPR PV
if we want to.