Re: [PATCH v19 039/130] KVM: TDX: initialize VM with TDX specific parameters

[Huang, Kai]

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@xxxxxxxxx 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?

Or is there anything special rule for using metadata field ID in the guest?

    {
      "Control Structure": "TDCS",
      "Class": "Execution Controls",
      "Field Name": "CONFIG_FLAGS",
      "Description": [
        "Non-attested TD configuration flags"
      ],
      "Type": "64b bitmap",
      "VM Applicability": null,
      "Mutability": "TDH.MNG.INIT/  TDH.IMPORT.STATE.IMMUTABLE",
      "Initial Value": "From TDH.MNG.INIT input",
      "Field Size (Bytes)": "8",
      "Num Fields": "1",
      "Num Elements": "1",
      "Element Size (Bytes)": "8",
      "Overall Size (Bytes)": "8",
      "Base FIELD_ID (Hex)": "0x9110000300000016",
      "Host VMM Access for a Production TD": "RO",
      "Host VMM Access for a Debug TD": "RO",
      "Guest Access": "RO",
      "Migration TD Access": "RO",
      "Host VMM Rd Mask for a Production TD ": "-1",
      "Host VMM Wr Mask for a Production TD ": "0",
      "Host VMM Rd Mask for a Debug TD ": "-1",
      "Host VMM Wr Mask for a Debug TD ": "0",
      "Guest Rd Mask": "-1",
      "Guest Wr Mask": "0",
      "Migration TD Rd Mask": "-1",
      "Migration TD wr Mask": "0"
    },