Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp46940pxb; Tue, 5 Oct 2021 22:56:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyss2z6P45VBKZ60C+MuAiO9GRJGU45bg+adv8+8X+/tcnF4Edb/woIqtAvEeRkCLKzOxq/ X-Received: by 2002:a17:906:585a:: with SMTP id h26mr29425446ejs.31.1633499775674; Tue, 05 Oct 2021 22:56:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633499775; cv=none; d=google.com; s=arc-20160816; b=zzDm2QA5XDK9wev8N3tqM8O6sYHO0UsLGtkHdXfHgzVg2Xd3r3YfBnky5+7h50l+5+ FRQfCcvYc5RZcUGOTDdXRPXvwD96FDWGK8d3PUPLxNwUNg5nmO6ttlqPzTu7oCN4y4ZM CUdJ194r76ocmGZHpQhe5h5ACT6pc9hp5FzQB7EcLUKNNlEsFUuxQ1rihehVpfowULj0 vsQKLuRyPpVd9Re+jx6xrh6hEJQXmysQBxMDZA92WVdf25bsAyI6lwzi4+uB8+41Jwcs E9Md60ZDe7xtQ+dKGv0BwheYfoL4g6rE28/v0KquD4QBxwfdkEcNDH5DZzCUCceiGq26 O08Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=o4AZ2v0d2upoVgn5yMh1nIi8K7ql02Ob+W4jg2mRZPo=; b=z8Kziay51Ipd3qY0Q0zqFhTHNB/hSo34EVdlN84kdww6KaXZLbJ3gRUyo80UJyuUgK NUbCVgKlvtb34VOE4xxkp38zHwP8RZba42mg9NUEaj9yzAphJJxk/WIZXVulxZxWrr3R NifWfY/nD5iTcXxl2jsrJYUowyzIQmP1bP3IEBEeEwQr8qGwRAeIuIT2xWgKwTN/ZfII V6gNjboMHg38ILzwfaYmxmXbqGX0sypZarTROIh7swpc97dpQ06HnvWng85QzPodwtQZ NUX3Q9WIe/prBigTNhrVx58IlsxBYE1ysAmBdn/n0wQekG5iLN/AMuDLL/aM7t+rsPV1 lb+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Q7G5LN3X; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h4si25130217ejo.291.2021.10.05.22.55.52; Tue, 05 Oct 2021 22:56:15 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Q7G5LN3X; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229956AbhJFF4A (ORCPT + 99 others); Wed, 6 Oct 2021 01:56:00 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:26452 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229621AbhJFFz7 (ORCPT ); Wed, 6 Oct 2021 01:55:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633499647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o4AZ2v0d2upoVgn5yMh1nIi8K7ql02Ob+W4jg2mRZPo=; b=Q7G5LN3X4R4b83DsKo/cShZWcStW6Ph+ptEupbfiumV+wQzqGDq8cCoTBHxdTMO6pHSWhS R+928jPR/sHfshcQh04oeeb0pZYPgzELTAS/y1haWbJuojRGGeWk3Rr89I+XWXdcbZMZmm DJXNrq44A7T2Yvx/+RxYN/OaxodCJ1c= Received: from mail-oo1-f72.google.com (mail-oo1-f72.google.com [209.85.161.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-273-ev8l8bhXOTSbLw1-MIL4Xg-1; Wed, 06 Oct 2021 01:54:04 -0400 X-MC-Unique: ev8l8bhXOTSbLw1-MIL4Xg-1 Received: by mail-oo1-f72.google.com with SMTP id i1-20020a4a9001000000b002a9c41e0eabso1139513oog.3 for ; Tue, 05 Oct 2021 22:54:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=o4AZ2v0d2upoVgn5yMh1nIi8K7ql02Ob+W4jg2mRZPo=; b=z/Ngv3eZue3yytekEZWNWMhOXSU+hhMEKaQFDTz3vtPuz7hP9hALkdMt+MZakOWXWn Jt5em7pZceOYk7vjQZIhRXt0qnF+/RgTfTRM+zPZO55EyhGDp2vBwoEJfo+7ddng1eyL j6SnKw1gDeeeSpt8QZ6jBBPKRgCZHXpmletfZUyjytJrIxVuVzMci2j72hYfLUctIt6k KFjb59kRc+bOrIcnshLKmt4Uu5VNEQ75/UZhWvwX/oVIr8JflrzCKozUilhVA32iYZQq Up8ALP4H2Ge4zKpVqUK43EsF76zieq6sQymmlznygRIbDONC/0ao54ErwmSeTGRYV1UG UagA== X-Gm-Message-State: AOAM532+jMYy/vxYr8Za4G/8AL/aDH12nU5zqS/CyUz3IVSzAR/5pDGV pihbs/ss3e8gNAXT/m+t++KDrNdQbVsCwWZXaQlD+qM19LU98x04q+N8q1WgayVAupP6kGBQFeX ki3oiVoLiopBTzWkTT2aQA9Ng X-Received: by 2002:a54:4807:: with SMTP id j7mr5725603oij.140.1633499643370; Tue, 05 Oct 2021 22:54:03 -0700 (PDT) X-Received: by 2002:a54:4807:: with SMTP id j7mr5725589oij.140.1633499643163; Tue, 05 Oct 2021 22:54:03 -0700 (PDT) Received: from treble ([2600:1700:6e32:6c00::15]) by smtp.gmail.com with ESMTPSA id i15sm432037otu.67.2021.10.05.22.54.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 22:54:02 -0700 (PDT) Date: Tue, 5 Oct 2021 22:53:59 -0700 From: Josh Poimboeuf To: Kuppuswamy Sathyanarayanan Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, Paolo Bonzini , David Hildenbrand , Andrea Arcangeli , Juergen Gross , Deep Shah , VMware Inc , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Peter H Anvin , Dave Hansen , Tony Luck , Dan Williams , Andi Kleen , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 05/11] x86/tdx: Add __tdx_module_call() and __tdx_hypercall() helper functions Message-ID: <20211006055359.svcqk36btq7zg3td@treble> References: <20211005025205.1784480-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20211005025205.1784480-6-sathyanarayanan.kuppuswamy@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211005025205.1784480-6-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 04, 2021 at 07:51:59PM -0700, Kuppuswamy Sathyanarayanan wrote: > Guests communicate with VMMs with hypercalls. Historically, these > are implemented using instructions that are known to cause VMEXITs > like VMCALL, VMLAUNCH, etc. However, with TDX, VMEXITs no longer > expose guest state to the host.  This prevents the old hypercall > mechanisms from working. So to communicate with VMM, TDX > specification defines a new instruction called TDCALL. > > In a TDX based VM, since VMM is an untrusted entity, a intermediary > layer (TDX module) exists between host and guest to facilitate > secure communication. TDX guests communicate with the TDX module > using TDCALL instruction.  Most of the information in the second paragraph was already provided in the first paragraph. > +#ifdef CONFIG_FRAME_POINTER > +/* Frame offset + 8 (for arg1) */ > +#define ARG7_SP_OFFSET (FRAME_OFFSET + 0x08) > +#else > +#define ARG7_SP_OFFSET (0x08) > +#endif No need for the #ifdef here, FRAME_OFFSET is already zero for !FRAME_POINTER. So it can just be unconditional: #define ARG7_SP_OFFSET (FRAME_OFFSET + 0x08) > + * __tdx_hypercall() - Helper function used by TDX guests to request > + * services from the VMM. All requests are made via the TDX module > + * using TDCALL instruction. > + * > + * This function serves as a wrapper to move user call arguments to the > + * correct registers as specified by TDCALL ABI and share it with VMM > + * via the TDX module. After TDCALL operation, output from the VMM is > + * saved to the memory specified in the "out" (struct tdx_hypercall_output) > + * pointer.  > + * > + *------------------------------------------------------------------------- > + * TD VMCALL ABI: > + *------------------------------------------------------------------------- > + * > + * Input Registers: > + * > + * RAX - TDCALL instruction leaf number (0 - TDG.VP.VMCALL) > + * RCX - BITMAP which controls which part of TD Guest GPR > + * is passed as-is to VMM and back. > + * R10 - Set 0 to indicate TDCALL follows standard TDX ABI > + * specification. Non zero value indicates vendor > + * specific ABI. > + * R11 - VMCALL sub function number > + * RBX, RBP, RDI, RSI - Used to pass VMCALL sub function specific arguments. > + * R8-R9, R12–R15 - Same as above. > + * > + * Output Registers: > + * > + * RAX - TDCALL instruction status (Not related to hypercall > + * output). > + * R10 - Hypercall output error code. > + * R11-R15 - Hypercall sub function specific output values. > + * > + *------------------------------------------------------------------------- > + * > + * __tdx_hypercall() function ABI: > + * > + * @type (RDI) - TD VMCALL type, moved to R10 > + * @fn (RSI) - TD VMCALL sub function, moved to R11 > + * @r12 (RDX) - Input parameter 1, moved to R12 > + * @r13 (RCX) - Input parameter 2, moved to R13 > + * @r14 (R8) - Input parameter 3, moved to R14 > + * @r15 (R9) - Input parameter 4, moved to R15 > + * > + * @out (stack) - struct tdx_hypercall_output pointer (cannot be NULL) > + * > + * On successful completion, return TDCALL status or -EINVAL for invalid > + * inputs. > + */ The documentation and comments for all the asm code are excellent! If only all kernel asm code were this readable! I'm especially thankful that it's not all crammed into inline asm :-) > +SYM_FUNC_START(__tdx_hypercall) > + FRAME_BEGIN > + > + /* Move argument 7 from caller stack to RAX */ > + movq ARG7_SP_OFFSET(%rsp), %rax > + > + /* Check if caller provided an output struct */ > + test %rax, %rax > + /* If out pointer is NULL, return -EINVAL */ > + jz 1f > + > + /* Save callee-saved GPRs as mandated by the x86_64 ABI */ > + push %r15 > + push %r14 > + push %r13 > + push %r12 > + > + /* > + * Save R9 and output pointer (rax) in stack, it will be used > + * again when storing the output registers after TDCALL > + * operation. > + */ > + push %r9 > + push %rax r9 is callee-clobbered, so we shouldn't need to push it here or pop it ("Restore state of R9 register" below) before returning. > +/* > + * Wrapper for standard use of __tdx_hypercall with BUG_ON() check > + * for TDCALL error. > + */ > +static inline u64 _tdx_hypercall(u64 fn, u64 r12, u64 r13, u64 r14, > + u64 r15, struct tdx_hypercall_output *out) Instead of calling the args r12-r15, I'm thinking it would be clearer to call them arg1-arg4. It's not the C code's job to worry about the argument-to-register ABI mappings. Same comment for the function declaration in the header file. -- Josh