[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: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [PATCH qemu] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it
Date: Tue, 15 Mar 2016 21:30:25 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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 <address@hidden>


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

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


reply via email to

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