From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afmFj-0003ga-6Y for qemu-devel@nongnu.org; Tue, 15 Mar 2016 06:31:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afmF5-0006LZ-M0 for qemu-devel@nongnu.org; Tue, 15 Mar 2016 06:31:03 -0400 References: <1458021080-2145-1-git-send-email-aik@ozlabs.ru> <20160315095952.GF9032@voom> From: Alexander Graf Message-ID: <56E7E43C.6030906@suse.de> Date: Tue, 15 Mar 2016 11:30:20 +0100 MIME-Version: 1.0 In-Reply-To: <20160315095952.GF9032@voom> Content-Type: text/plain; charset=windows-1252 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: David Gibson , Alexey Kardashevskiy Cc: Paul Mackerras , qemu-ppc@nongnu.org, qemu-devel@nongnu.org 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 > > 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