Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6803944rwb; Tue, 22 Nov 2022 20:04:22 -0800 (PST) X-Google-Smtp-Source: AA0mqf44nx366sooWAzP6eEmseX760izuEHX8Z+dX2ymTSw7jodYLwQNQBaHSdi0InH1icsrOTiv X-Received: by 2002:a65:67c3:0:b0:477:96e2:beb8 with SMTP id b3-20020a6567c3000000b0047796e2beb8mr6911412pgs.151.1669176261897; Tue, 22 Nov 2022 20:04:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669176261; cv=none; d=google.com; s=arc-20160816; b=m2DScJ1f8YZ4z73SyZ2o4JZiTL8dGGPvnJDB6A/035eotR/itASOOL9ezH+Ib6AU8e 5dFhHRVBlBLErMU6gvyFe+nmg1JNi4Zclv6RbnBE+SdawPuxaDsM1HVkm/skTPKeXuhK Cwye5Yi4oqRgNqy8Q1e9ZlQHFtiR+QHEi1vTxhTI3VcV2qbfxVBj1Hu+eNuwGjI7FSUZ /DbPN7P3w1wm89krVAHCKTyUilqDTz8hJa8odzn+atJCQfGRYhljpgMBUzq06B7CeYBx 0uUfbkBGFN/NqY6aLfjGbRJpvgwdJ28hAArbtTb/5pSjQKrvfE6cOlajQ3EgC/LfmT3W jZTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=hAqu0yBrYuss7GZm9CleMxgWSfX65eWpAg55kJdK8GU=; b=oK06YmrP2lf9izJdxJrSBPxjtYn9sOmap0RM9TuWqWlNjJB4trl9+R6d98NJrOO2rW sD+SeTfCJzl6h2DqsMKvBUTXPRwfJVFW1d0l9Fb7vjyLrNlTh2aV5Bl71m6aS4rcHIQK Zp88YkWjzDqjC4Rm4DXNW3jW9nl8h06k7F7WG98PDwwOCuQf0DnHgbVlOKJhDUnjB05b ULs4A//6fKZuR4QCeUCza3luJowIMKcO4+9IaZCVyu1y9tNA3auTeaoKUtlX/uMPBsf1 yt1gSSOxTBgeFvCZWXKo5f0xzhL8S4v31lmoalOls/uJH23eeWF/IFTcYNOxW0ilUPSG 3PBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=IRmPOAk2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x1-20020a623101000000b00562a956d979si13517431pfx.67.2022.11.22.20.04.02; Tue, 22 Nov 2022 20:04:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=IRmPOAk2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235649AbiKWDwQ (ORCPT + 89 others); Tue, 22 Nov 2022 22:52:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234375AbiKWDwO (ORCPT ); Tue, 22 Nov 2022 22:52:14 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF481DB84F; Tue, 22 Nov 2022 19:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669175533; x=1700711533; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=vJeCuU0PZMiUtuycmN2gWAkeimzciZJYcvOH8AE6Ihc=; b=IRmPOAk2yiX5NfPavL2h4gVbJ0sgTyviQZldwN7IgHjMNaHNRIN8xkCA d3xKa2utGef/Qy/z+eNfOBuUAhhgsRfb1Vdfs4X3JZDzZu3l6OwG9UnrP 2quYFfSLrPi9Zd1TL1waot1+DadhiyV4W/htS+sdsI+32nhuuC/vgqxcF hZTavDvjkF34bwyLvVc+cA1kHgzQq/BKBzCumVeh3pgZzQV0AGSVUXQ13 N7cdztcR7QPe051/N0w1AhL06DuZIhuLkvDjlESAYI2lxZEsS3TTnc2p5 14+tNhpoupcW+Vxbh0CszNogILBbXPI02cWChT7JDWDB3k0KOBhC57DQN Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10539"; a="312673186" X-IronPort-AV: E=Sophos;i="5.96,186,1665471600"; d="scan'208";a="312673186" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2022 19:52:12 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10539"; a="730636013" X-IronPort-AV: E=Sophos;i="5.96,186,1665471600"; d="scan'208";a="730636013" Received: from mjalalif-mobl1.amr.corp.intel.com (HELO [10.255.229.245]) ([10.255.229.245]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2022 19:52:11 -0800 Message-ID: <08a42493-0ff5-3b29-e6a5-db622e8d4c7f@linux.intel.com> Date: Tue, 22 Nov 2022 19:52:05 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 Subject: Re: [PATCH 1/6] x86/tdx: Support hypercalls for TDX guests on Hyper-V Content-Language: en-US To: Dexuan Cui , Dave Hansen , "ak@linux.intel.com" , "arnd@arndb.de" , "bp@alien8.de" , "brijesh.singh@amd.com" , "Williams, Dan J" , "dave.hansen@linux.intel.com" , Haiyang Zhang , "hpa@zytor.com" , "jane.chu@oracle.com" , "kirill.shutemov@linux.intel.com" , KY Srinivasan , "linux-arch@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "luto@kernel.org" , "mingo@redhat.com" , "peterz@infradead.org" , "rostedt@goodmis.org" , "seanjc@google.com" , "tglx@linutronix.de" , "tony.luck@intel.com" , "wei.liu@kernel.org" , "x86@kernel.org" Cc: "linux-kernel@vger.kernel.org" References: <20221121195151.21812-1-decui@microsoft.com> <20221121195151.21812-2-decui@microsoft.com> <18323d11-146f-c418-e8f0-addb2b8adb19@intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/22/22 5:37 PM, Dexuan Cui wrote: >> From: Dave Hansen >> Sent: Monday, November 21, 2022 12:39 PM >> [...] >> On 11/21/22 11:51, Dexuan Cui wrote: >>> __tdx_hypercall() doesn't work for a TDX guest running on Hyper-V, >>> because Hyper-V uses a different calling convention, so add the >>> new function __tdx_ms_hv_hypercall(). >> >> Other than R10 being variable here and fixed for __tdx_hypercall(), this >> looks *EXACTLY* the same as __tdx_hypercall(), or at least a strict >> subset of what __tdx_hypercall() can do. >> >> Did I miss something? > > The existing asm code for __tdx_hypercall() passes through R10~R15 > (see TDVMCALL_EXPOSE_REGS_MASK) to the (KVM) hypervisor. > > Unluckily, for Hyper-V, we need to pass through RDX, R8, R10 and R11 > to Hyper-V, so I don't think I can use the existing __tdx_hypercall() ? > >> Another way of saying this: It seems like you could do this with a new >> version of _tdx_hypercall() (and all in C) instead of a new >> __tdx_hypercall(). > > I don't think the current TDVMCALL_EXPOSE_REGS_MASK allows me > to pass through RDX and R8 to Hyper-V. Because TDVMCALLs defined in the GHCI specification only use registers R10-R15, only those registers are currently exposed. However, the TDVMCALL ABI allows the use of input registers such as RBX, RBP, RDI, RSI, R8 or R9. Instead of creating a new variant of __tdx_hypercall() to handle your use case, perhaps you can add the registers you require to the TDVMCALL EXPOSE REGS MASK. You just need to make sure they are zeroed out for other users of __tdx_hypercall(). > > PS, the comment before __tdx_hypercall() contains this line: > > "* RBX, RBP, RDI, RSI - Used to pass VMCALL sub function specific > arguments." > > But it looks like currently RBX an RBP are not used at all in > arch/x86/coco/tdx/tdcall.S ? > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer