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 <a...@ozlabs.ru> > --- > > > 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. Alex
