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;
Date:   Tue, 25 Jul 2023 08:36:09 -0700
In-Reply-To: <9e8a98ad-1f8d-a09c-3173-71c5c3ab5ed4@intel.com>
Mime-Version: 1.0
References: <cover.1689893403.git.isaku.yamahata@intel.com>
 <8c0b7babbdd777a33acd4f6b0f831ae838037806.1689893403.git.isaku.yamahata@intel.com>
 <ZLqbWFnm7jyB8JuY@google.com> <9e8a98ad-1f8d-a09c-3173-71c5c3ab5ed4@intel.com>
Message-ID: <ZL/r6Vca8WkFVaic@google.com>
Subject: Re: [RFC PATCH v4 09/10] KVM: x86: Make struct sev_cmd common for KVM_MEM_ENC_OP
From:   Sean Christopherson <seanjc@google.com>
To:     Xiaoyao Li <xiaoyao.li@intel.com>
Cc:     isaku.yamahata@intel.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com,
        Michael Roth <michael.roth@amd.com>,
        Paolo Bonzini <pbonzini@redhat.com>, erdemaktas@google.com,
        Sagi Shahar <sagis@google.com>,
        David Matlack <dmatlack@google.com>,
        Kai Huang <kai.huang@intel.com>,
        Zhi Wang <zhi.wang.linux@gmail.com>, chen.bo@intel.com,
        linux-coco@lists.linux.dev,
        Chao Peng <chao.p.peng@linux.intel.com>,
        Ackerley Tng <ackerleytng@google.com>,
        Vishal Annapurve <vannapurve@google.com>,
        Yuan Yao <yuan.yao@linux.intel.com>
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Tue, Jul 25, 2023, Xiaoyao Li wrote:
> On 7/21/2023 10:51 PM, Sean Christopherson wrote:
> > On Thu, Jul 20, 2023, isaku.yamahata@intel.com wrote:
> > > diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> > > index aa7a56a47564..32883e520b00 100644
> > > --- a/arch/x86/include/uapi/asm/kvm.h
> > > +++ b/arch/x86/include/uapi/asm/kvm.h
> > > @@ -562,6 +562,39 @@ struct kvm_pmu_event_filter {
> > >   /* x86-specific KVM_EXIT_HYPERCALL flags. */
> > >   #define KVM_EXIT_HYPERCALL_LONG_MODE	BIT(0)
> > > +struct kvm_mem_enc_cmd {
> > > +	/* sub-command id of KVM_MEM_ENC_OP. */
> > > +	__u32 id;
> > > +	/*
> > > +	 * Auxiliary flags for sub-command.  If sub-command doesn't use it,
> > > +	 * set zero.
> > > +	 */
> > > +	__u32 flags;
> > > +	/*
> > > +	 * Data for sub-command.  An immediate or a pointer to the actual
> > > +	 * data in process virtual address.  If sub-command doesn't use it,
> > > +	 * set zero.
> > > +	 */
> > > +	__u64 data;
> > > +	/*
> > > +	 * Supplemental error code in the case of error.
> > > +	 * SEV error code from the PSP or TDX SEAMCALL status code.
> > > +	 * The caller should set zero.
> > > +	 */
> > > +	union {
> > > +		struct {
> > > +			__u32 error;
> > > +			/*
> > > +			 * KVM_SEV_LAUNCH_START and KVM_SEV_RECEIVE_START
> > > +			 * require extra data. Not included in struct
> > > +			 * kvm_sev_launch_start or struct kvm_sev_receive_start.
> > > +			 */
> > > +			__u32 sev_fd;
> > > +		};
> > > +		__u64 error64;
> > > +	};
> > > +};
> > 
> > Eww.  Why not just use an entirely different struct for TDX?  I don't see what
> > benefit this provides other than a warm fuzzy feeling that TDX and SEV share a
> > struct.  Practically speaking, KVM will likely take on more work to forcefully
> > smush the two together than if they're separate things.
> 
> generalizing the struct of KVM_MEM_ENC_OP should be the first step.

It's not just the one structure though.  The "data" field is a pointer to yet
another layer of commands, and SEV has a rather big pile of those.  Making
kvm_mem_enc_cmd common is just putting lipstick on a pig since the vast majority
of the structures associated with the ioctl() would still be vendor specific.

  struct kvm_sev_launch_start
  struct kvm_sev_launch_update_data
  struct kvm_sev_launch_secret
  struct kvm_sev_launch_measure
  struct kvm_sev_guest_status
  struct kvm_sev_dbg
  struct kvm_sev_attestation_report
  struct kvm_sev_send_start
  struct kvm_sev_send_update_data
  struct kvm_sev_receive_start
  struct kvm_sev_receive_update_data

FWIW, I really dislike KVM's uAPI for KVM_MEM_ENC_OP.  The above structures are
all basically copied verbatim from PSP firmware structures, i.e. the commands and
their payloads are tightly coupled to "hardware" and essentially have no abstraction
whatsoever.   But that ship has already sailed, and practically speaking trying to
provide a layer of abstraction might not of worked very well anyways.

In other words, unless there's an obvious and easy way path to convergence, I
recommend you don't spend much time/effort on trying to share code with TDX.