[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH qemu] spapr/target-ppc/kvm: Only add hcall-instr

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH qemu] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it
Date: Tue, 15 Mar 2016 11:19:49 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]