lkml.org 
[lkml]   [2021]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Q. about KVM and CPU hotplug
Date
> From: Paolo Bonzini <paolo.bonzini@gmail.com>
> Sent: Wednesday, December 1, 2021 12:27 AM
>
> On 11/30/21 15:05, Thomas Gleixner wrote:
> > Why is this hotplug callback in the CPU starting section to begin with?
>
> Just because the old notifier implementation used CPU_STARTING - in fact
> the commit messages say that CPU_STARTING was added partly *for* KVM
> (commit e545a6140b69, "kernel/cpu.c: create a CPU_STARTING cpu_chain
> notifier", 2008-09-08).
>
> > If you stick it into the online section which runs on the hotplugged CPU
> > in thread context:
> >
> > CPUHP_AP_ONLINE_IDLE,
> >
> > --> CPUHP_AP_KVM_STARTING,
> >
> > CPUHP_AP_SCHED_WAIT_EMPTY,
> >
> > then it is allowed to fail and it still works in the right way.
>
> Yes, moving it to the online section should be fine; it wouldn't solve
> the TDX problem however. Failure would rollback the hotplug and forbid
> hotplug altogether when TDX is loaded, which is not acceptable.
>

Fail hotplug just because TDX is loaded is not acceptable.

But fail hotplug when a trusted domain using TDX is active imo makes
sense. It's similar philosophy to VMX which, with above change, will
fail hotplug when kvm_usage_count is non-zero (implying a VM is
active) but VMX initialization fails on this CPU. We can add similar
tdx_usage_count to mark active TDX users and forbid hotplug
when this variable is non-zero.

In general I think it's an acceptable policy to fail an operation if it
breaks active existing usages... 😊

Thanks
Kevin
\
 
 \ /
  Last update: 2021-12-01 08:19    [W:0.344 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site