On 15.03.16 10:59, David Gibson wrote: > On Tue, Mar 15, 2016 at 04:51:20PM +1100, 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> > > So the idea of only adding the property when the host kernel supplies > a suitable value seems good, but I'm a bit nervous about applying > this, because I'm not sure what case the original fallback hypercall > code was supposed to handle. > > agraf, if you could enlighten us with some history that could be good.
The fallback code simply does "return -1" regardless of guest endianness, so it makes every kvm hypercall fail. I guess not supplying the sequence at all if the host kernel doesn't implement kvm hypercalls (and thus doesn't expose the trampoline), yeah. I wonder why I didn't do that back then, hrm .. Alex
