Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753068AbdDJJHk (ORCPT ); Mon, 10 Apr 2017 05:07:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48754 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750989AbdDJJHj (ORCPT ); Mon, 10 Apr 2017 05:07:39 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9E8444E4D0 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=vkuznets@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9E8444E4D0 From: Vitaly Kuznetsov To: Jork Loeser Cc: "devel\@linuxdriverproject.org" , "x86\@kernel.org" , "linux-kernel\@vger.kernel.org" , "KY Srinivasan" , Haiyang Zhang , Stephen Hemminger , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Steven Rostedt Subject: Re: [PATCH 2/7] x86/hyper-v: fast hypercall implementation References: <20170407112701.17157-1-vkuznets@redhat.com> <20170407112701.17157-3-vkuznets@redhat.com> Date: Mon, 10 Apr 2017 11:07:34 +0200 In-Reply-To: (Jork Loeser's message of "Fri, 7 Apr 2017 19:42:10 +0000") Message-ID: <87vaqc8wbt.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 10 Apr 2017 09:07:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2357 Lines: 68 Jork Loeser writes: >> -----Original Message----- >> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com] >> Sent: Friday, April 7, 2017 04:27 >> To: devel@linuxdriverproject.org; x86@kernel.org >> Cc: linux-kernel@vger.kernel.org; KY Srinivasan ; >> Haiyang Zhang ; Stephen Hemminger >> ; Thomas Gleixner ; Ingo >> Molnar ; H. Peter Anvin ; Steven >> Rostedt ; Jork Loeser >> Subject: [PATCH 2/7] x86/hyper-v: fast hypercall implementation > >> diff --git a/arch/x86/include/asm/mshyperv.h >> b/arch/x86/include/asm/mshyperv.h index 331e834..9a5f58b 100644 >> --- a/arch/x86/include/asm/mshyperv.h >> +++ b/arch/x86/include/asm/mshyperv.h >> @@ -216,6 +216,43 @@ static inline u64 hv_do_hypercall(u64 control, void >> *input, void *output) #endif /* !x86_64 */ } >> >> +/* Fast hypercall with 8 bytes of input and no output */ static inline >> +u64 hv_do_fast_hypercall8(u16 code, u64 input1) { >> + union hv_hypercall_input control = {0}; >> + >> + control.code = code; >> + control.fast = 1; >> +#ifdef CONFIG_X86_64 >> + { >> + u64 hv_status; >> + >> + __asm__ __volatile__("call *%3" >> + : "=a" (hv_status) >> + : "c" (control.as_uint64), "d" (input1), >> + "m" (hv_hypercall_pg) >> + : "cc", "r8", "%r9", "%r10", "%r11"); >> + return hv_status; > Clobber memory (are there such fast hypercalls)? > Hm, I was under an impression fast hypercalls have no output or put the output in XMM* registers and we don't use them for now. Why clobbering memory? >> + } >> +#else >> + { >> + u32 hv_status_hi, hv_status_lo; >> + >> + __asm__ __volatile__ ("call *%6" >> + : "=d"(hv_status_hi), >> + "=a"(hv_status_lo) : >> + "d" (control.as_uint32_hi), >> + "a" (control.as_uint32_lo), >> + "c" ((u32)input1), >> + "b" ((u32)(input1 >> 32)), >> + "m" (hv_hypercall_pg) >> + : "cc"); >> + >> + return hv_status_lo | ((u64)hv_status_hi << 32); >> + } >> +#endif > Please clobber ECX, EDI and ESI for x86. Clobber memory as well? ECX is already in listed in inputs (lower part of input1) so it's automatically clobbered. I'll add EDI and ESI to clobbers here, thanks! -- Vitaly