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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CC2DC433F5 for ; Tue, 19 Apr 2022 03:54:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244701AbiDSD4j (ORCPT ); Mon, 18 Apr 2022 23:56:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346696AbiDSD4e (ORCPT ); Mon, 18 Apr 2022 23:56:34 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 080BC1C108; Mon, 18 Apr 2022 20:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650340430; x=1681876430; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=wwVlV46Os/EgjaHAxLPUSBeF8ua2q+Qb6p8RYQe/FoU=; b=jvsTG9ae4l9Zyxc6ewUbz8Dacu2WB3DXjmYEblKNmx7VHp3q6dM39kH5 D9eWBhMpx2mHZT2PmwoVGfasXiP5wgzZLKw41XuKz+ZmLcMqXQXavhNuX pkPeiADZ+aCxYcG13CLi6WU5tV3y0z9OV9G/gG4Po+3kIdDvSmNCIW1Dt hWPNs7N35pRwPzeVmfxhjSw4OdwvLv2DhHNeSHPlx59hqXIhtPfacCxn9 XVZ+vRWOevWiFcuAJ+vcfFn84iC88sP8xWWE4qa+vcnP+z/FgqnVzUejC pUKh6tevS3tZSqjkoBGqzeb57Fsq2PhzNjbGDv9htCEplRygbiO4Wrrq2 Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10321"; a="250970495" X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="250970495" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2022 20:53:49 -0700 X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="657486395" Received: from chferrer-mobl.amr.corp.intel.com (HELO [10.209.37.31]) ([10.209.37.31]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2022 20:53:40 -0700 Message-ID: Date: Mon, 18 Apr 2022 20:53:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.7.0 Subject: Re: [PATCH v3 1/4] x86/tdx: Add tdx_mcall_tdreport() API support Content-Language: en-US To: Kai Huang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Hans de Goede , Mark Gross Cc: "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org References: <20220415220109.282834-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220415220109.282834-2-sathyanarayanan.kuppuswamy@linux.intel.com> <283f3d9ec19597856521e66895348e80ef51f10a.camel@intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: <283f3d9ec19597856521e66895348e80ef51f10a.camel@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/18/22 8:51 PM, Kai Huang wrote: >> Users are responsible to allocate aligned data. I don't think we need >> to add a check for it. If it is unaligned, TDCALL will return error. > Actually this is the kernel memory, but not user memory. Otherwise > virt_to_phys() doesn't make sense. You copied the user data to kernel memory in > the last patch. So whether user memory is aligned doesn't matter, and in last > patch, you have guaranteed the alignment is met during kernel memory allocation. I mean't user of this API (not user space). But I agree with your comments. -- Sathyanarayanan Kuppuswamy Linux Kernel Developer