Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3146663ybh; Mon, 16 Mar 2020 17:00:02 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsIHyyuY0aIm+G+8VyjWxkyQwKNC0gxYmyrGsmlyRvlz8a7WWp30muqxPvvVRwT5OkKCRAl X-Received: by 2002:aca:5191:: with SMTP id f139mr1607041oib.140.1584403201938; Mon, 16 Mar 2020 17:00:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584403201; cv=none; d=google.com; s=arc-20160816; b=P12I4r1to4A9zFnaZVAjULrLUgHA+jQXdNDxam5R3GUcDuiZuDkzcEbuGFdZat9HOM kxOa4WPNQ3C900bpRbzw/WLhUnIX/eFHprfaSsOmAXbNXkaz+0+juOJ3myPh4rcnS+Dp 3Dow8Nt0l1ZHE/lFR3e+wRvXgNtln4usq3/1r+8w1fT2lRBWEo8c9Op3GAxtVjAC9tKL bkn0wEdmyy89+5C/TZHVBD3rSQdMxfOG/GAnBipIuaFyAAW+kN3Nby4tkmz19Py7Xnp4 aJNOeYWUyTHGjlp+1OtbNVpzDmfJfruf2QkRX76Q+rBt6ZSUxTbM4FEyY2E9jND92fD4 BuQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=pyrLvb+EI1jxoeSF75VcnoDYH21OVns5z/e/Z+FK+FE=; b=v/wZ1wRZE9OiiBRnG4JhgtkRMDXBJ38Qqo24aTR2g/J5KTKpZ51C7elrN244RfbYKX ohoc2GoawZ6+z3D3p5hOa5cRu7O2t26WlOhSWQbcxliBikrwgBkUA8ZbDa9uJW1LUQIm rLtOGI9aKHHs7Tv43+Yi41YHdXXDrSmTtFpw0lEs8piERE+ygocetETuUva54XYMgIUk Zcf//BBe3RiJv1PilE9r0xxbGYyY5ibUn1mao/eryrgSJjphF+wuUtth4VPbkorXEd2Z 2UVolW4Q1/gJ2NDL45YmEa8C9FPZih9/YJPplSWg3y9vEcmw/HHCVzyS3Dt+wwIckgK2 1wew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t185si762924oie.70.2020.03.16.16.59.48; Mon, 16 Mar 2020 17:00:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732994AbgCPX4p (ORCPT + 99 others); Mon, 16 Mar 2020 19:56:45 -0400 Received: from mga11.intel.com ([192.55.52.93]:49033 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732977AbgCPX4p (ORCPT ); Mon, 16 Mar 2020 19:56:45 -0400 IronPort-SDR: eKRMza+1TLqcIExZrXkqF3lTUnWDDGkoInq4knORL7F5DQlchGBGOmVOlopSK7sn04nrFR5Yyr 5cA+h8I8AOyw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2020 16:56:45 -0700 IronPort-SDR: uECgVr6/klVPAgp+iMzMUAOBIA0UfpBRAfaKDaluds/TyUrFHHfnKiGX00ZNVE8vJ/fuqtmLhx B6/0vT6Qqkpg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,562,1574150400"; d="scan'208";a="244308878" Received: from bxing-mobl.amr.corp.intel.com (HELO [10.135.8.145]) ([10.135.8.145]) by orsmga003.jf.intel.com with ESMTP; 16 Mar 2020 16:56:42 -0700 Subject: Re: [PATCH v28 21/22] x86/vdso: Implement a vDSO for Intel SGX enclave call To: Sean Christopherson , Jethro Beekman Cc: Nathaniel McCallum , Jarkko Sakkinen , linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org, akpm@linux-foundation.org, dave.hansen@intel.com, Neil Horman , "Huang, Haitao" , andriy.shevchenko@linux.intel.com, tglx@linutronix.de, "Svahn, Kai" , bp@alien8.de, Josh Triplett , luto@kernel.org, kai.huang@intel.com, David Rientjes , Patrick Uiterwijk , Andy Lutomirski , Connor Kuehl , Harald Hoyer , Lily Sturmann References: <20200303233609.713348-1-jarkko.sakkinen@linux.intel.com> <20200303233609.713348-22-jarkko.sakkinen@linux.intel.com> <20200315012523.GC208715@linux.intel.com> <7f9f2efe-e9af-44da-6719-040600f5b351@fortanix.com> <20200316225534.GK24267@linux.intel.com> From: "Xing, Cedric" Message-ID: <7634c48d-a8e2-7366-6f04-06a27f8e5eaf@intel.com> Date: Mon, 16 Mar 2020 16:56:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200316225534.GK24267@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/16/2020 3:55 PM, Sean Christopherson wrote: > On Mon, Mar 16, 2020 at 02:31:36PM +0100, Jethro Beekman wrote: >> Can someone remind me why we're not passing TCS in RBX but on the stack? > > I finally remembered why. It's pulled off the stack and passed into the > exit handler. I'm pretty sure the vDSO could take it in %rbx and manually > save it on the stack, but I'd rather keep the current behavior so that the > vDSO is callable from C (assuming @leaf is changed to be passed via %rcx). > The idea is that the caller of this vDSO API is C callable, hence it cannot receive TCS in %rbx anyway. Then it has to either MOV to %rbx or PUSH to stack. Either way the complexity is the same. The vDSO API however has to always save it on stack for exit handler. So receiving it via stack ends up in simplest code.