Received-SPF: pass (google.com: domain of linux-kernel+bounces-191923-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 28 May 2024 11:19:25 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: "Huang, Kai" <kai.huang@intel.com>
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, 
	"Yamahata, Isaku" <isaku.yamahata@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, "Aktas, Erdem" <erdemaktas@google.com>, 
	Sean Christopherson <seanjc@google.com>, Sagi Shahar <sagis@google.com>, "Chen, Bo2" <chen.bo@intel.com>, 
	"Yuan, Hang" <hang.yuan@intel.com>, "Zhang, Tina" <tina.zhang@intel.com>, 
	"Li, Xiaoyao" <Xiaoyao.Li@intel.com>
Subject: Re: [PATCH v19 039/130] KVM: TDX: initialize VM with TDX specific
 parameters
Message-ID: <fagj35jsiktyxegcyb6jujq2tkwzgnvqjfebka2eybdmzhpxej@m4ycvcqow5kt>
References: <cover.1708933498.git.isaku.yamahata@intel.com>
 <5eca97e6a3978cf4dcf1cff21be6ec8b639a66b9.1708933498.git.isaku.yamahata@intel.com>
 <46mh5hinsv5mup2x7jv4iu2floxmajo2igrxb3haru3cgjukbg@v44nspjozm4h>
 <de344d2c-6790-49c5-85be-180bc4d92ea4@suse.com>
 <etso5bvvs2gq3parvzukujgbatwqfb6lhzoxhenrapav6obbgl@o6lowhrcbucp>
 <e8b36230-d59f-44f1-ba48-5a0533238d8e@suse.com>
 <pfbphwefaefxw2l2u26qr6ptq7rtdmnihjmxvk34zv4srlnsum@qyjumzzdnfxo>
 <46713df6-d73e-4816-bbda-a3b2dc723438@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <46713df6-d73e-4816-bbda-a3b2dc723438@intel.com>

On Fri, May 24, 2024 at 11:37:15AM +1200, Huang, Kai wrote:
> 
> 
> On 18/05/2024 4:25 am, Kirill A. Shutemov wrote:
> > On Fri, May 17, 2024 at 05:00:19PM +0200, J?rgen Gro? wrote:
> > > On 17.05.24 16:53, Kirill A. Shutemov wrote:
> > > > On Fri, May 17, 2024 at 04:37:16PM +0200, Juergen Gross wrote:
> > > > > On 17.05.24 16:32, Kirill A. Shutemov wrote:
> > > > > > On Mon, Feb 26, 2024 at 12:25:41AM -0800, isaku.yamahata@intel.com wrote:
> > > > > > > @@ -725,6 +967,17 @@ static int __init tdx_module_setup(void)
> > > > > > >     	tdx_info->nr_tdcs_pages = tdcs_base_size / PAGE_SIZE;
> > > > > > > +	/*
> > > > > > > +	 * Make TDH.VP.ENTER preserve RBP so that the stack unwinder
> > > > > > > +	 * always work around it.  Query the feature.
> > > > > > > +	 */
> > > > > > > +	if (!(tdx_info->features0 & MD_FIELD_ID_FEATURES0_NO_RBP_MOD) &&
> > > > > > > +	    !IS_ENABLED(CONFIG_FRAME_POINTER)) {
> > > > > > 
> > > > > > I think it supposed to be IS_ENABLED(CONFIG_FRAME_POINTER). "!" shouldn't
> > > > > > be here.
> > > > > 
> > > > > No, I don't think so.
> > > > > 
> > > > > With CONFIG_FRAME_POINTER %rbp is being saved and restored, so there is no
> > > > > problem in case the seamcall is clobbering it.
> > > > 
> > > > Could you check setup_tdparams() in your tree?
> > > > 
> > > > Commit
> > > > 
> > > > [SEAM-WORKAROUND] KVM: TDX: Don't use NO_RBP_MOD for backward compatibility
> > > > 
> > > > in my tree comments out the setting TDX_CONTROL_FLAG_NO_RBP_MOD.
> > > > 
> > > > I now remember there was problem in EDK2 using RBP. So the patch is
> > > > temporary until EDK2 is fixed.
> > > > 
> > > 
> > > I have the following line in setup_tdparams() (not commented out):
> > > 
> > > 	td_params->exec_controls = TDX_CONTROL_FLAG_NO_RBP_MOD;
> > 
> > Could you check if it is visible from the guest side?
> > 
> > It is zero for me.
> > 
> > diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> > index c1cb90369915..f65993a6066d 100644
> > --- a/arch/x86/coco/tdx/tdx.c
> > +++ b/arch/x86/coco/tdx/tdx.c
> > @@ -822,13 +822,33 @@ static bool tdx_enc_status_change_finish(unsigned long vaddr, int numpages,
> >   	return true;
> >   }
> > +#define TDG_VM_RD			7
> > +
> > +#define TDCS_CONFIG_FLAGS		0x1110000300000016
> > +
> 
> Hi Kirill,
> 
> Where did you get this metadata field ID value from?  I assume you meant
> below one, from which the ID is 0x9110000300000016?

The ID has changed in recent JSON ABI definitions. Looks fishy. I will
find out what is going on.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov