Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp70496pxk; Wed, 30 Sep 2020 18:14:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1LJtj7LcL/kAsH0XBOVuQneVN/iHN9wURuWgeCxdGihfWkWd50eiq/7c2m7JTPKeM/57+ X-Received: by 2002:a17:906:2454:: with SMTP id a20mr5563552ejb.294.1601514842901; Wed, 30 Sep 2020 18:14:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601514842; cv=none; d=google.com; s=arc-20160816; b=mluJEcGyltR5V6VxWYaQcUmmKj4uEjbAuQwBefS97IKqFRPgX1FRrylcFKbf4QyRI5 sunpbcE+axVTo5O5Q4HAItB8I9rC51nL6jBpqsJX846all39D96wOBdAZ1TLU/ktSC6w 85frML77JTpdw449uGteyl98lQnyfajhnqj2+hF7y+lNxLoAYtkcstSuJcXenkrUvDwm KmBPJcdZ1mnrWJvj/uFAYs/p1LFdfx6m1AGxxVlCxE4YWp2wwtTXgayHDYKY/nfNmiB1 YXV9jGqTHv82vVrBpW0+NgmZp9NusSzMqdRb3AzzBfCtv4ns+UjO12lrcdrWY0ev+i/O n2mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Uw3DahuKoaaRF+FNCC5CY2ROGev1Y3ara+4tR8G+W7w=; b=Lq+n3iBDsNy5JulpAruPqhWNqquOmLD/uT0Uc1DncNsNwt/WKIE5fZF/fp95rh1GeO yiqWIzJ3+1/9Y1jm4BXXTak54korXpDg3RjDoc78EbJaGH1+fd765w0Yj8vfvEd2x+5y eTX7mDFxgtE7cO8wAjkCWeHt66TbFnQEOgRNJPIeGM7RQ73VE6ucXm6UFgGecrDrs7Hf bNZ+KPMe8boBMsD+eBJQxzyQsj+VDI/xtyKCWs+M4thCUC1/OiDpwRWfbbvsT7G/ZLwO KysPlKFTxLJPOzK30ygGZo2ElCDO/bQT/lExIrzL50vSzMukK6snNM9ncwI0PUmw54jY pHvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s26si2150581edx.578.2020.09.30.18.13.39; Wed, 30 Sep 2020 18:14:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731445AbgJAAQE (ORCPT + 99 others); Wed, 30 Sep 2020 20:16:04 -0400 Received: from gate.crashing.org ([63.228.1.57]:48298 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729980AbgJAAQD (ORCPT ); Wed, 30 Sep 2020 20:16:03 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 09108Yfg011750; Wed, 30 Sep 2020 19:08:34 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 09108XYC011749; Wed, 30 Sep 2020 19:08:33 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 30 Sep 2020 19:08:32 -0500 From: Segher Boessenkool To: Arvind Sankar Cc: Nick Desaulniers , Peter Zijlstra , Dave Hansen , Greg Kroah-Hartman , shuo.a.liu@intel.com, LKML , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Sean Christopherson , Yu Wang , Reinette Chatre , Yakui Zhao , Dan Williams , Fengwei Yin , Zhi Wang , Zhenyu Wang Subject: Re: [PATCH v4 04/17] x86/acrn: Introduce hypercall interfaces Message-ID: <20201001000832.GE28786@gate.crashing.org> References: <20200922114311.38804-1-shuo.a.liu@intel.com> <20200922114311.38804-5-shuo.a.liu@intel.com> <20200927105152.GG88650@kroah.com> <6f9a2b83-6904-2290-6c4f-526672390beb@intel.com> <20200930111612.GZ2628@hirez.programming.kicks-ass.net> <20200930161036.GY28786@gate.crashing.org> <20200930171346.GC2628@hirez.programming.kicks-ass.net> <20200930195915.GA3180913@rani.riverdale.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200930195915.GA3180913@rani.riverdale.lan> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 03:59:15PM -0400, Arvind Sankar wrote: > On Wed, Sep 30, 2020 at 12:14:03PM -0700, Nick Desaulniers wrote: > > On Wed, Sep 30, 2020 at 10:13 AM Peter Zijlstra wrote: > > > > > > On Wed, Sep 30, 2020 at 11:10:36AM -0500, Segher Boessenkool wrote: > > > > > > > Since this variable is a local register asm, on entry to the asm the > > > > compiler guarantees that the value lives in the assigned register (the > > > > "r8" hardware register in this case). This all works completely fine. > > > > This is the only guaranteed behaviour for local register asm (well, > > > > together with analogous behaviour for outputs). > > How strict is the guarantee? This is an inline function -- could the > compiler decide to reorder some other code in between the r8 assignment > and the asm statement when it gets inlined? Nope. It will be in r8 on entry to the asm. A guarantee is a guarantee; it is not a "yeah maybe, we'll see". > > Do we need register local storage here? > > > > static inline long bar(unsigned long hcall_id) > > { > > long result; > > asm volatile("movl %1, %%r8d\n\t" > > "vmcall\n\t" > > : "=a" (result) > > : "ir" (hcall_id) > > : ); > > return result; > > } > > This seems more robust, though you probably need an r8 clobber in there? Oh, x86 has the operand order inverted, so this should work in fact. Segher