From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE5C3C433ED for ; Tue, 11 May 2021 01:07:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78D6F615FF for ; Tue, 11 May 2021 01:07:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230096AbhEKBI1 (ORCPT ); Mon, 10 May 2021 21:08:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229980AbhEKBIY (ORCPT ); Mon, 10 May 2021 21:08:24 -0400 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6D16C061574 for ; Mon, 10 May 2021 18:07:18 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id y26so20864678eds.4 for ; Mon, 10 May 2021 18:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z0A7p7l5UlP8ih6gnzpDJkXYmkZR04hOiCwPZ3G9az8=; b=uNSvNZJ7I2aVfpuVnun3OImfHtqcBraJYnFx2nsnhRGMPyAzddwShYZHnuadmC6aIU nNUWuPVfJtb8RLVOV3qAVaSzECkFXifsQv/AyDgs9vCD6L5qlONknM7gqhrmPe64NU3H Vu7UEFN/qlbDfqNNeTyOmeRIb3jTtqZMGdweHDJWq1ex5XT0Snz+bPwGlz/3bt0seiT0 rtnPut1QJxc1F2+w+ya2bNlsCyXQ8smids2fYh/4YGZQ+7E2TULcEkTqddHuXUgCgBqn HCN99OdaEvBRD9LFY0EtM75OlkIE8bmBQ372e0HpKHvPwTdFG9XDHl/JViawCgegLh8U Qhbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z0A7p7l5UlP8ih6gnzpDJkXYmkZR04hOiCwPZ3G9az8=; b=ila9gQ7LMnyvY+5nmvYV0owYPhPKGHxzd4anRJ/RjRBWTtHCIF3CXJ5MOPob4IxtAz 8g2g4yNu57ePT5CNDCw38R/piYx45XHxITzgmy9A8ar4Zb5kQVzdyp3ecRkYvP6d/r6q oclWiyZhqPvGQYKlqawqSP1GYiEa7QdIIfqEq/AciNHo2DQcBIN1MTS1U7cWCZEA8MPG jD182YDED3U9mjiCtmX0nYj7xz5T+cw+hUKZKktiKmSmaaJiJJAh9bklJCyFFKRN/icT KduCB/KBIgsUSNnPUMNNNQv1OEcx+02Pq5gTbPCTevrAykG6yBEIREEGqZl2LFAgr/J3 +pyw== X-Gm-Message-State: AOAM5305/WxJs8MMVPMhhgbztR8EvcuM8WxB6/ZsGeaQNzmEUq8+JZ3j atVL0kbimq+IegjFNZFo0D19fLgUqczFWtnABBdP2w== X-Google-Smtp-Source: ABdhPJxYbgRMZM0H/Wq57eZV/1LKPdxOJPhErfwz6aDX58ob9rzKsdOdOvKGYPeQl6GBbnbbziXAVRIxt/P+O5srP20= X-Received: by 2002:a50:ff13:: with SMTP id a19mr32734675edu.300.1620695237437; Mon, 10 May 2021 18:07:17 -0700 (PDT) MIME-Version: 1.0 References: <0e7e94d1ee4bae49dfd0dd441dc4f2ab6df76668.1619458733.git.sathyanarayanan.kuppuswamy@linux.intel.com> <9f89a317-11fa-d784-87a8-37124891900c@linux.intel.com> In-Reply-To: <9f89a317-11fa-d784-87a8-37124891900c@linux.intel.com> From: Dan Williams Date: Mon, 10 May 2021 18:07:06 -0700 Message-ID: Subject: Re: [RFC v2 14/32] x86/tdx: Handle port I/O To: "Kuppuswamy, Sathyanarayanan" Cc: Andi Kleen , Peter Zijlstra , Andy Lutomirski , Dave Hansen , Tony Luck , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Raj Ashok , Sean Christopherson , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 10, 2021 at 5:30 PM Kuppuswamy, Sathyanarayanan wrote: [..] > It is mainly used by functions like __tdx_hypercall(),__tdx_hypercall_vendor_kvm() > and tdx_in{b,w,l}. > > u64 __tdx_hypercall(u64 fn, u64 r12, u64 r13, u64 r14, u64 r15, > struct tdx_hypercall_output *out); > u64 __tdx_hypercall_vendor_kvm(u64 fn, u64 r12, u64 r13, u64 r14, > u64 r15, struct tdx_hypercall_output *out); > > struct tdx_hypercall_output { > u64 r11; > u64 r12; > u64 r13; > u64 r14; > u64 r15; > }; Why is this by register name and not something like: struct tdx_hypercall_payload { u64 data[5]; }; ...because the code in this patch is reading the payload out of a stack relative offset, not r11. > > > Functions like __tdx_hypercall() and __tdx_hypercall_vendor_kvm() are used > by TDX guest to request services (like RDMSR, WRMSR,GetQuote, etc) from VMM > using TDCALL instruction. do_tdx_hypercall() is the helper function (in > tdcall.S) which actually implements this ABI. > > As per current ABI, VMM will use registers R11-R15 to share the output > values with the guest. Which ABI, __tdx_hypercall_vendor_kvm()? The code is putting the payload on the stack, so I'm not sure what ABI you are referring to? > So we have defined the structure > struct tdx_hypercall_output to group all output registers and make it easier > to share it with users of the TDCALLs. This is Linux defined structure. > > If there are any changes in TDCALL ABI for VMM, we might have to extend > this structure to accommodate new output register changes. So if we > define TDVMCALL_OUTPUT_SIZE as 40, we will have modify this value for > any future struct tdx_hypercall_output changes. So to avoid it, we have > allocated double the size. > > May be I should define it as, > > #define TDVMCALL_OUTPUT_SIZE sizeof(struct tdx_hypercall_output) An arrangement like that seems more reasonable than a seemingly arbitrary number and an ominous warning about things that may happen in the future.