Re: [Qemu-devel] [PATCH qemu] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 03/15/2016 09:19 PM, Alexander Graf wrote:
>
>
> 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 <aik@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.

Like what? I did grep and could not spot many for pseries, only 
KVM_HC_FEATURES and KVM_HC_PPC_MAP_MAGIC_PAGE. I am suggesting here to hide 
this property from "pseries" guests only.


> 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.

I am not suggesting removing it, only advertise it if the KVM supports it...




-- 
Alexey