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 432DEC7EE23 for ; Wed, 7 Jun 2023 18:16:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230459AbjFGSQR (ORCPT ); Wed, 7 Jun 2023 14:16:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232351AbjFGSQL (ORCPT ); Wed, 7 Jun 2023 14:16:11 -0400 Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E23F626A1; Wed, 7 Jun 2023 11:15:48 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-6532671ccc7so6831622b3a.2; Wed, 07 Jun 2023 11:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686161739; x=1688753739; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=I1Bdx56ELbJV6dVhyhR5X8oZi1hZNlzrjaEbVK43zt0=; b=n+4h+HLEv7EtmjMbv4XFFywlwFrltstBuM8BlVU6O6baPWbwsPuzB8CIDradodZ9sk oovi1r+vTq+81F5PPTMSE7Pk+xfLqed6d8UntW66P5fxjDpqZzkmqcG7h1PBjpeO0+Hd 4bksgwvv/ULOalVkUPeZM5m/Jp3SQiHOekKOaFQdzGNzCTkgE8LO2soreHroIBOxRUlC Nr5H+zrh1ndKXPxNTdFeMAeqNn1wCpgmF1uqP11eZD3JEkGfSs/QrmEUO6UNZ71jDoUm Da0uv69LcxBjL3PbCo87IVTkgOJXB+O8t8mHAcSU3lPMRQv+j+utjBNcU37uU9Y2mzTL W53Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686161739; x=1688753739; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=I1Bdx56ELbJV6dVhyhR5X8oZi1hZNlzrjaEbVK43zt0=; b=A9TDFy6tkL82jdXHXF+OyFSkh9FFq5x/CEgH5/+ogeH4vSkfS9XkRLQwumjPCs6d9q gDr/UcSpirIWTx+s5oZBHJFUCYYwu7/oWSAMBQXOx01QaT2FOnD/SR+vskIuJ65OqXf0 Rq4KUhv9XqizxYMOPrpgu1AyG0dGhAu3R2viDai0ObtxcALgS4vkog3KiidI2y1G5K0k 36hRaK7jVsTQz3KuVbiJRqlbClRUk0QH2yj0e0DmFJHg/IJ7PkDIdn1zmtZSVywiFtAT AxavCqGBhQxvClMrISM6Nk7b2KC21obHmxI3clHEnVNyparp15kS7fEm5ZOryEDv8VjM L08Q== X-Gm-Message-State: AC+VfDwqHoOhTowKnDJ/nK7cferX0WywTStZhaZMFo48yQYewbOzEDPg puenZfWP2yt1TpV8CpP5l3zTgB75AozANQ== X-Google-Smtp-Source: ACHHUZ5/l4PYL/diZnBXO47WKC1iNZQbpyhoKSRt8h8KKmprcUXYCD2dnCbnJWNxoM6wWCRQ43cCyg== X-Received: by 2002:a05:6a00:180f:b0:663:13a9:9504 with SMTP id y15-20020a056a00180f00b0066313a99504mr162246pfa.10.1686161739462; Wed, 07 Jun 2023 11:15:39 -0700 (PDT) Received: from localhost ([192.55.54.50]) by smtp.gmail.com with ESMTPSA id b17-20020aa78111000000b0064dbf805ff7sm2587545pfi.72.2023.06.07.11.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 11:15:38 -0700 (PDT) Date: Wed, 7 Jun 2023 11:15:37 -0700 From: Isaku Yamahata To: "Wang, Wei W" Cc: "Yamahata, Isaku" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "isaku.yamahata@gmail.com" , Paolo Bonzini , "Aktas, Erdem" , "Christopherson,, Sean" , "Shahar, Sagi" , David Matlack , "Huang, Kai" , Zhi Wang , "Chen, Bo2" , Sean Christopherson Subject: Re: [PATCH v14 011/113] KVM: TDX: Add C wrapper functions for SEAMCALLs to the TDX module Message-ID: <20230607181537.GG2244082@ls.amr.corp.intel.com> References: <37b118268ccf73d8e9cc1ef8f9fb7376fb732d60.1685333727.git.isaku.yamahata@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 05, 2023 at 03:20:19PM +0000, "Wang, Wei W" wrote: > > diff --git a/arch/x86/kvm/vmx/tdx_ops.h b/arch/x86/kvm/vmx/tdx_ops.h > > new file mode 100644 index 000000000000..893cc6c25f3b > > --- /dev/null > > +++ b/arch/x86/kvm/vmx/tdx_ops.h > > @@ -0,0 +1,202 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* constants/data definitions for TDX SEAMCALLs */ > > + > > +#ifndef __KVM_X86_TDX_OPS_H > > +#define __KVM_X86_TDX_OPS_H > > + > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#include "tdx_errno.h" > > +#include "tdx_arch.h" > > +#include "x86.h" > > + > > +static inline u64 kvm_seamcall(u64 op, u64 rcx, u64 rdx, u64 r8, u64 r9, > > + struct tdx_module_output *out) { > > + u64 ret; > > + > > + ret = __seamcall(op, rcx, rdx, r8, r9, out); > > + if (unlikely(ret == TDX_SEAMCALL_UD)) { > > + /* > > + * TDX requires VMXON or #UD. In the case of reboot or > > kexec, > > + * VMX is made off (VMXOFF) by kvm reboot notifier, > > + * kvm_reboot(), while TDs are still running. The callers > > check > > + * the returned error and complain. Suppress it by returning 0. > > + */ > > Curious how do the callers check the returned error when " Suppress > it by returning 0" here. It doesn't make sense for the caller to check the error and warn when kvm_rebooting = true. Let's make it "return kvm_rebooting ? 0 : ret;" instread of "return 0;". Does it make sense? -- Isaku Yamahata