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

Huang, Kai
2024-05-23T23:37:29Z

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?

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"
},