From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afmFq-0003hZ-MX for qemu-devel@nongnu.org; Tue, 15 Mar 2016 06:32:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afmFG-0006QN-IP for qemu-devel@nongnu.org; Tue, 15 Mar 2016 06:31:10 -0400 Received: from mail-pf0-x243.google.com ([2607:f8b0:400e:c00::243]:36616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afmFF-0006P5-62 for qemu-devel@nongnu.org; Tue, 15 Mar 2016 06:30:34 -0400 Received: by mail-pf0-x243.google.com with SMTP id q129so2190663pfb.3 for ; Tue, 15 Mar 2016 03:30:33 -0700 (PDT) References: <1458021080-2145-1-git-send-email-aik@ozlabs.ru> <56E7E1C5.1040409@suse.de> From: Alexey Kardashevskiy Message-ID: <56E7E441.1090104@ozlabs.ru> Date: Tue, 15 Mar 2016 21:30:25 +1100 MIME-Version: 1.0 In-Reply-To: <56E7E1C5.1040409@suse.de> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-devel@nongnu.org Cc: Paul Mackerras , qemu-ppc@nongnu.org, David Gibson 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 >> --- >> >> >> 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