Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2233688pxm; Fri, 4 Mar 2022 11:59:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2XrNH49VdeHSe5yB0xZXIPQA6lJon2ypyxUnDldSDkobY7R8m6/MCBxI24R5N7LJoZNdc X-Received: by 2002:a50:cfc5:0:b0:414:83de:22c3 with SMTP id i5-20020a50cfc5000000b0041483de22c3mr145476edk.241.1646423967766; Fri, 04 Mar 2022 11:59:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646423967; cv=none; d=google.com; s=arc-20160816; b=VAxVWI6k/IVyIFUooNQVIx7oq2nN7GpdkMr0YARbOAKrHQWKWMDjRhftS7g5hUfS0M /pNUpWfDvzvdDN5Vic8qYjqpv/26IfPLb/awcmwQZVk/yIu6HVrZAnu3WdoBfDUhO/r/ xow+mhKOqtZ4Ae4/mKDvCB06Y//KdHcM0K8bEW0z54KPh+UEkFCcRF5eJmTwwF5Ji4KG Q7Kql7OhNBVDBfvWwQahN7k6Uq4+CO6X1kJ8P+ahqGt4/enIjPhjzAuAvImmxzQrNMHN gvT+t07lGSICABs+s0M0w8KCJn72gV8+v1Eg3KaCTtSx2Mdnk3Jm5HmScE7CvYWVwh5f W8Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=fvexmUN1JxeFmhJYz8M9PKIPee83iVV+1ZnG4j1kfos=; b=TmgUYP23K59mhJVYhPH96QYaN4A8bBNTixMoTU1RCQToCZ1uo1sjXPciyysS/QWepH X2xI5qSVmZj256hnhciYJeqcJ+NN9cFi8i0KYnTlmvRgST/ot7Fx9rHWVzFvAmFjJWFD SVxbPczubG/mTLOuAolGXzR2rlTfZpZD09DNWH5ch0FiAch+UMvgtQSWmt971id0QvOo AbompPhIfrKTigDxJ2oo6QRWBoKClff+CKZO20rfjr0dB/0uqjcsY1pIOLC4Y46y9J5f yMau2H41a2cMf8cvqKoGn9AEw2G6dFkiCG2Wd1CRXyzRrym/KWiE5NKHUj+4aan1C5PU fa9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JIOYX9fB; 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 nd33-20020a17090762a100b006da94ca35e1si4279921ejc.630.2022.03.04.11.59.04; Fri, 04 Mar 2022 11:59:27 -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=JIOYX9fB; 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 S229640AbiCDT7d (ORCPT + 99 others); Fri, 4 Mar 2022 14:59:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbiCDT7L (ORCPT ); Fri, 4 Mar 2022 14:59:11 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAAA8240DCF; Fri, 4 Mar 2022 11:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646423445; x=1677959445; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+nGQVrBe96XTUjrDdPql+9GcVxyKPhvOW6aWfhm10vM=; b=JIOYX9fBvqLcVEI9SkR95tYsDp0MPMUlICNvS/WyPgWv/AypE2v8sEa3 tLUH9ezx4Hr2hQ8Vyz7pHzgEgyCXej7nV2y7o8Ozy7Mql1phbXBKoAAMl EF4dIShw7m/8nE6tggKToX7cWegmTlSDI53Xx78sruNIaGYej9eRFu/8v OuhkUHGNT0vFaB/ZUF4XGbdaWJLp+AjZSpxu3+oW51Eq6yajsxKQVGfka NdLpEE/cxY05glAcytZLDJxHHFEK4NVl/3lfj55dtGvgMWLHzrDkOXgyE lyL+eCAysbwt7Hmt/O2+8V71U2fcasCG62cbshHVUUaLorlScHD9h85BK g==; X-IronPort-AV: E=McAfee;i="6200,9189,10276"; a="253779655" X-IronPort-AV: E=Sophos;i="5.90,156,1643702400"; d="scan'208";a="253779655" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 11:50:44 -0800 X-IronPort-AV: E=Sophos;i="5.90,156,1643702400"; d="scan'208";a="552344562" Received: from ls.sc.intel.com (HELO localhost) ([143.183.96.54]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 11:50:44 -0800 From: isaku.yamahata@intel.com To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: isaku.yamahata@intel.com, isaku.yamahata@gmail.com, Paolo Bonzini , Jim Mattson , erdemaktas@google.com, Connor Kuehl , Sean Christopherson Subject: [RFC PATCH v5 092/104] KVM: TDX: Handle TDX PV HLT hypercall Date: Fri, 4 Mar 2022 11:49:48 -0800 Message-Id: <6da55adb2ddb6f287ebd46aad02cfaaac2088415.1646422845.git.isaku.yamahata@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE 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 From: Isaku Yamahata Wire up TDX PV HLT hypercall to the KVM backend function. When the guest issues HLT, the hypercall instruction can be the right after CLI instruction. Atomically unmask virtual interrupt and issue HLT hypercall. The virtual interrupts can arrive right after CLI instruction before switching back to VMM. In such a case, the VMM should return to the guest without losing the interrupt. Check if interrupts arrived before the TDX module switching to VMM. And return to the guest in such cases. Signed-off-by: Isaku Yamahata --- arch/x86/kvm/vmx/tdx.c | 45 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c index f7c9170d596a..b0dcc2421649 100644 --- a/arch/x86/kvm/vmx/tdx.c +++ b/arch/x86/kvm/vmx/tdx.c @@ -917,6 +917,48 @@ static int tdx_emulate_cpuid(struct kvm_vcpu *vcpu) return 1; } +static int tdx_emulate_hlt(struct kvm_vcpu *vcpu) +{ + bool interrupt_disabled = tdvmcall_p1_read(vcpu); + union tdx_vcpu_state_details details; + + tdvmcall_set_return_code(vcpu, TDG_VP_VMCALL_SUCCESS); + + if (!interrupt_disabled) { + /* + * Virtual interrupt can arrive after TDG.VM.VMCALL during + * the TDX module executing. On the other hand, KVM doesn't + * know if vcpu was executing in the guest TD or the TDX module. + * + * CPU mode transition: + * TDG.VP.VMCALL (SEAM VMX non-root mode) -> + * the TDX module (SEAM VMX root mode) -> + * KVM (Legacy VMX root mode) + * + * If virtual interrupt arrives to this vcpu + * - In the guest TD executing: + * KVM can handle it in the same way to the VMX case. + * - During the TDX module executing: + * The TDX modules switches to KVM with TDG.VM.VMCALL + * exit reason. KVM thinks the guest was running. So KVM + * vcpu wake up logic doesn't kick in. Check if virtual + * interrupt is pending and resume vcpu without blocking vcpu. + * - KVM executing: + * The existing logic wakes up the target vcpu on injecting + * virtual interrupt in the same way to the VMX case. + * + * Check if the interrupt is already pending. If yes, resume + * vcpu from guest HLT without emulating hlt instruction. + */ + details.full = td_state_non_arch_read64( + to_tdx(vcpu), TD_VCPU_STATE_DETAILS_NON_ARCH); + if (details.vmxip) + return 1; + } + + return kvm_emulate_halt_noskip(vcpu); +} + static int handle_tdvmcall(struct kvm_vcpu *vcpu) { struct vcpu_tdx *tdx = to_tdx(vcpu); @@ -930,7 +972,8 @@ static int handle_tdvmcall(struct kvm_vcpu *vcpu) switch (tdvmcall_exit_reason(vcpu)) { case EXIT_REASON_CPUID: return tdx_emulate_cpuid(vcpu); - + case EXIT_REASON_HLT: + return tdx_emulate_hlt(vcpu); default: break; } -- 2.25.1