Message-ID: <eb37d3fc-7d19-4dc2-bac4-6e0cb5c8aa1e@intel.com>
Date: Thu, 21 Nov 2024 07:38:06 +0800
From: "Huang, Kai" <kai.huang@...el.com>
To: Chao Gao <chao.gao@...el.com>
CC: <pbonzini@...hat.com>, <seanjc@...gle.com>, <kvm@...r.kernel.org>,
	<rick.p.edgecombe@...el.com>, <isaku.yamahata@...el.com>,
	<reinette.chatre@...el.com>, <binbin.wu@...ux.intel.com>,
	<xiaoyao.li@...el.com>, <yan.y.zhao@...el.com>, <adrian.hunter@...el.com>,
	<tony.lindgren@...el.com>, <kristen@...ux.intel.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] KVM: VMX: Initialize TDX during KVM module load



On 18/11/2024 2:22 pm, Chao Gao wrote:
>> +static int tdx_online_cpu(unsigned int cpu)
>> +{
>> +	unsigned long flags;
>> +	int r;
>> +
>> +	/* Sanity check CPU is already in post-VMXON */
>> +	WARN_ON_ONCE(!(cr4_read_shadow() & X86_CR4_VMXE));
>> +
>> +	local_irq_save(flags);
>> +	r = tdx_cpu_enable();
>> +	local_irq_restore(flags);
> 
> The comment above tdx_cpu_enable() is outdated because now it may be called
> from CPU hotplug rather than IPI function calls only.
> 
> Can we relax the assertion lockdep_assert_irqs_disabled() in tdx_cpu_enable()?
> looks the requirement is just the enabling work won't be migrated and done to
> another CPU.

We can but I don't want to do it now.  We will need to revist both 
tdx_cpu_enable() and tdx_enable() when we move VMXON out of KVM anyway. 
I would like to focus on bringing KVM TDX support first and then to 
revisit them together at that timeframe.

> 
>> +
>> +	return r;
>> +}
>> +
>> +static void __do_tdx_cleanup(void)
>> +{
>> +	/*
>> +	 * Once TDX module is initialized, it cannot be disabled and
>> +	 * re-initialized again w/o runtime update (which isn't
>> +	 * supported by kernel).  Only need to remove the cpuhp here.
>> +	 * The TDX host core code tracks TDX status and can handle
>> +	 * 'multiple enabling' scenario.
>> +	 */
>> +	WARN_ON_ONCE(!tdx_cpuhp_state);
>> +	cpuhp_remove_state_nocalls(tdx_cpuhp_state);
> 
> ...
> 
>> +	tdx_cpuhp_state = 0;
>> +}
>> +
>> +static int __init __do_tdx_bringup(void)
>> +{
>> +	int r;
>> +
>> +	/*
>> +	 * TDX-specific cpuhp callback to call tdx_cpu_enable() on all
>> +	 * online CPUs before calling tdx_enable(), and on any new
>> +	 * going-online CPU to make sure it is ready for TDX guest.
>> +	 */
>> +	r = cpuhp_setup_state_cpuslocked(CPUHP_AP_ONLINE_DYN,
>> +					 "kvm/cpu/tdx:online",
>> +					 tdx_online_cpu, NULL);
>> +	if (r < 0)
>> +		return r;
>> +
>> +	tdx_cpuhp_state = r;
>> +
>> +	r = tdx_enable();
>> +	if (r)
>> +		__do_tdx_cleanup();
> 
> this calls cpuhp_remove_state_nocalls(), which acquires cpu locks again,
> causing a potential deadlock IIUC.

Dam.. I'll fix. Thanks for catching.

> 
>> +
>> +	return r;
>> +}
>> +
>> +static bool __init kvm_can_support_tdx(void)
> 
> I think "static __init bool" is the preferred order. see
> 
> https://www.kernel.org/doc/html/latest/process/coding-style.html#function-prototypes

I think you are right, but IIUC we'd better to change all the existing 
'static <ret_type> __init' to 'static __init <ret_type>' in KVM code. 
I'd rather to keep the current way to make them aligned and we can 
change them at once if needed in the future.

> 
>> +{
>> +	return cpu_feature_enabled(X86_FEATURE_TDX_HOST_PLATFORM);
>> +}
>> +
>> +static int __init __tdx_bringup(void)
>> +{
>> +	int r;
>> +
>> +	/*
>> +	 * Enabling TDX requires enabling hardware virtualization first,
>> +	 * as making SEAMCALLs requires CPU being in post-VMXON state.
>> +	 */
>> +	r = kvm_enable_virtualization();
>> +	if (r)
>> +		return r;
>> +
>> +	cpus_read_lock();
>> +	r = __do_tdx_bringup();
>> +	cpus_read_unlock();
>> +
>> +	if (r)
>> +		goto tdx_bringup_err;
>> +
>> +	/*
>> +	 * Leave hardware virtualization enabled after TDX is enabled
>> +	 * successfully.  TDX CPU hotplug depends on this.
>> +	 */
> 
> Shouldn't we make enable_tdx dependent on enable_virt_at_load? Otherwise, if
> someone sets enable_tdx=1 and enable_virt_at_load=0, they will get hardware
> virtualization enabled at load time while enable_virt_at_load still shows 0.
> This behavior is a bit confusing to me.
> 
> I think a check against enable_virt_at_load in kvm_can_support_tdx() will work.
> 
> The call of kvm_enable_virtualization() here effectively moves
> kvm_init_virtualization() out of kvm_init() when enable_tdx=1. I wonder if it
> makes more sense to refactor out kvm_init_virtualization() for non-TDX cases
> as well, i.e.,
> 
>    vmx_init();
>    kvm_init_virtualization();
>    tdx_init();
>    kvm_init();
> 
> I'm not sure if this was ever discussed. To me, this approach is better because
> TDX code needn't handle virtualization enabling stuff. It can simply check that
> enable_virt_at_load=1, assume virtualization is enabled and needn't disable
> virtualization on errors.

I think this was briefly discussed here:

https://lore.kernel.org/all/ZrrFgBmoywk7eZYC@google.com/

The disadvantage of splitting out kvm_init_virtualization() is all other 
ARCHs (all non-TDX cases actually) will need to explicitly call 
kvm_init_virtualization() separately.

> 
> A bonus is that on non-TDX-capable systems, hardware virtualization won't be
> toggled twice at KVM load time for no good reason.

I am fine with either way.

Sean, do you have any comments?

Powered by blists - more mailing lists