[v4,1/8] KVM: VMX: Move out vmx_x86_ops to 'main.c' to wrap VMX and TDX

From: Sean Christopherson <sean.j.christopherson@intel.com>

From: Sean Christopherson <sean.j.christopherson@intel.com>

KVM accesses Virtual Machine Control Structure (VMCS) with VMX instructions
to operate on VM.  TDX defines its data structure and TDX SEAMCALL APIs for
VMM to operate on Trust Domain (TD) instead.

Trust Domain Virtual Processor State (TDVPS) is the root control structure
of a TD VCPU.  It helps the TDX module control the operation of the VCPU,
and holds the VCPU state while the VCPU is not running. TDVPS is opaque to
software and DMA access, accessible only by using the TDX module interface
functions (such as TDH.VP.RD, TDH.VP.WR ,..).  TDVPS includes TD VMCS, and
TD VMCS auxiliary structures, such as virtual APIC page, virtualization
exception information, etc.  TDVPS is composed of Trust Domain Virtual
Processor Root (TDVPR) which is the root page of TDVPS and Trust Domain
Virtual Processor eXtension (TDVPX) pages which extend TDVPR to help
provide enough physical space for the logical TDVPS structure.

Also, we have a new structure, Trust Domain Control Structure (TDCS) is the
main control structure of a guest TD, and encrypted (using the guest TD's
ephemeral private key).  At a high level, TDCS holds information for
controlling TD operation as a whole, execution, EPTP, MSR bitmaps, etc. KVM
needs to set it up.  Note that MSR bitmaps are held as part of TDCS (unlike
VMX) because they are meant to have the same value for all VCPUs of the
same TD.  TDCS is a multi-page logical structure composed of multiple Trust
Domain Control Extension (TDCX) physical pages.  Trust Domain Root (TDR) is
the root control structure of a guest TD and is encrypted using the TDX
global private key. It holds a minimal set of state variables that enable
guest TD control even during times when the TD's private key is not known,
or when the TD's key management state does not permit access to memory
encrypted using the TD's private key.

The following shows the relationship between those structures.

        TDR--> TDCS                     per-TD
         |       \--> TDCX
         \
          \--> TDVPS                    per-TD VCPU
                 \--> TDVPR and TDVPX

The existing global struct kvm_x86_ops already defines an interface which
fits with TDX.  But kvm_x86_ops is system-wide, not per-VM structure.  To
allow VMX to coexist with TDs, the kvm_x86_ops callbacks will have wrappers
"if (tdx) tdx_op() else vmx_op()" to switch VMX or TDX at run time.

To split the runtime switch, the VMX implementation, and the TDX
implementation, add main.c, and move out the vmx_x86_ops hooks in
preparation for adding TDX, which can coexist with VMX, i.e. KVM can run
both VMs and TDs.  Use 'vt' for the naming scheme as a nod to VT-x and as a
concatenation of VmxTdx.

The current code looks as follows.
In vmx.c
  static vmx_op() { ... }
  static struct kvm_x86_ops vmx_x86_ops = {
        .op = vmx_op,
  initialization code

The eventually converted code will look like
In vmx.c, keep the VMX operations.
  vmx_op() { ... }
  VMX initialization
In tdx.c, define the TDX operations.
  tdx_op() { ... }
  TDX initialization
In x86_ops.h, declare the VMX and TDX operations.
  vmx_op();
  tdx_op();
In main.c, define common wrappers for VMX and VMX.
  static vt_ops() { if (tdx) tdx_ops() else vmx_ops() }
  static struct kvm_x86_ops vt_x86_ops = {
        .op = vt_op,
  initialization to call VMX and TDX initialization

Opportunistically, fix the name inconsistency from vmx_create_vcpu() and
vmx_free_vcpu() to vmx_vcpu_create() and vxm_vcpu_free().

Co-developed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
---
 arch/x86/kvm/Makefile      |   2 +-
 arch/x86/kvm/vmx/main.c    | 154 ++++++++++++++++
 arch/x86/kvm/vmx/vmx.c     | 360 +++++++++++--------------------------
 arch/x86/kvm/vmx/x86_ops.h | 126 +++++++++++++
 4 files changed, 385 insertions(+), 257 deletions(-)
 create mode 100644 arch/x86/kvm/vmx/main.c
 create mode 100644 arch/x86/kvm/vmx/x86_ops.h

Message ID	a2b9ed19d9f7bda70050ebbeb0a57bd4dbd6865a.1645266955.git.isaku.yamahata@intel.com (mailing list archive)
State	New, archived
Headers	show Return-Path: <kvm-owner@kernel.org> 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 01F65C433EF for <kvm@archiver.kernel.org>; Sat, 19 Feb 2022 18:50:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242977AbiBSSuy (ORCPT <rfc822;kvm@archiver.kernel.org>); Sat, 19 Feb 2022 13:50:54 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:45494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243001AbiBSSuS (ORCPT <rfc822;kvm@vger.kernel.org>); Sat, 19 Feb 2022 13:50:18 -0500 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D3B070043; Sat, 19 Feb 2022 10:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645296596; x=1676832596; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=oFf+X/erSNcVTNiegG4nLpE0tBBHfWJ1c3O1NvBLU94=; b=f7B8pwmiSP/qdMg+bolifMgdgqhVDluATTfPHlgyQXapPmMRQa42JMvy abr8C4GiwxTZMt8/t9xUCLf4r/KNhzZlVH+h1BaeYcD6XVLfUpyRuNVtV M8gLzE0UmmdjengPa9Q2oYiG1nPtg9rUc/IGZYsZPlpf3IRg6qprCkt3G APn8o2CH3dCfcHOgtPxHCZnjzcesGd9+t402MaJxQiJumgJcVFiS/6blS MM0KhFua1JhuK+gAY8neKwdqRxXG4ATQWGFsDfzsKzHTVJmmLLltHM5JX x13vi8N9h3KlLYrzfuOaTJi1JSo8AQpTdV3V/aehu8iqlHE24GQOTgGCm g==; X-IronPort-AV: E=McAfee;i="6200,9189,10263"; a="312058993" X-IronPort-AV: E=Sophos;i="5.88,381,1635231600"; d="scan'208";a="312058993" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2022 10:49:54 -0800 X-IronPort-AV: E=Sophos;i="5.88,381,1635231600"; d="scan'208";a="507137023" Received: from ls.sc.intel.com (HELO localhost) ([143.183.96.54]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2022 10:49:54 -0800 From: isaku.yamahata@intel.com To: Thomas Gleixner <tglx@linutronix.de>, Borislav Petkov <bp@alien8.de>, Paolo Bonzini <pbonzini@redhat.com>, Jim Mattson <jmattson@google.com>, erdemaktas@google.com, Connor Kuehl <ckuehl@redhat.com>, Sean Christopherson <seanjc@google.com>, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: isaku.yamahata@intel.com, isaku.yamahata@gmail.com Subject: [PATCH v4 1/8] KVM: VMX: Move out vmx_x86_ops to 'main.c' to wrap VMX and TDX Date: Sat, 19 Feb 2022 10:49:46 -0800 Message-Id: <a2b9ed19d9f7bda70050ebbeb0a57bd4dbd6865a.1645266955.git.isaku.yamahata@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <cover.1645266955.git.isaku.yamahata@intel.com> References: <cover.1645266955.git.isaku.yamahata@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <kvm.vger.kernel.org> X-Mailing-List: kvm@vger.kernel.org
Series	KVM TDX: preparation for coexistence of VMX and TDX \| expand [v4,0/8] KVM TDX: preparation for coexistence of VMX and TDX [v4,1/8] KVM: VMX: Move out vmx_x86_ops to 'main.c' to wrap VMX and TDX [v4,2/8] KVM: TDX: Detect CPU feature on kernel module initialization [v4,3/8] KVM: Enable hardware before doing arch VM initialization [v4,4/8] KVM: x86: Refactor KVM VMX module init/exit functions [v4,5/8] KVM: TDX: Add placeholders for TDX VM/vcpu structure [v4,6/8] KVM: TDX: Add a function to initialize TDX module [v4,7/8] KVM: x86: Introduce vm_type to differentiate default VMs from confidential VMs [v4,8/8] KVM: TDX: Make TDX VM type supported

[v4,1/8] KVM: VMX: Move out vmx_x86_ops to 'main.c' to wrap VMX and TDX

Commit Message

Patch