[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230227214809.GJ4175971@ls.amr.corp.intel.com>
Date: Mon, 27 Feb 2023 13:48:09 -0800
From: Isaku Yamahata <isaku.yamahata@...il.com>
To: "Huang, Kai" <kai.huang@...el.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Shahar, Sagi" <sagis@...gle.com>,
"Aktas, Erdem" <erdemaktas@...gle.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
"dmatlack@...gle.com" <dmatlack@...gle.com>,
"Christopherson,, Sean" <seanjc@...gle.com>
Subject: Re: [PATCH v11 021/113] KVM: TDX: Refuse to unplug the last cpu on
the package
On Mon, Jan 16, 2023 at 10:23:16AM +0000,
"Huang, Kai" <kai.huang@...el.com> wrote:
> On Thu, 2023-01-12 at 08:31 -0800, isaku.yamahata@...el.com wrote:
> > From: Isaku Yamahata <isaku.yamahata@...el.com>
> >
> > In order to reclaim TDX HKID, (i.e. when deleting guest TD), needs to call
> > TDH.PHYMEM.PAGE.WBINVD on all packages. If we have used TDX HKID, refuse
> > to offline the last online cpu. Add arch callback for cpu offline.
>
> I think it is worth to talk about suspend staff, i.e. why we only refuse to
> offline the last cpu when there's active TD, but not choose to offline the last
> cpu when TDX is enabled in KVM. People may not be able to understand
> immediately the reason behind this design.
Updated the comment.
> Btw, I certainly don't want to speak for Sean, but it seems this was suggested
> by Sean? If so, add a 'Suggested-by' tag?
Added suggested-by.
> >
> > Signed-off-by: Isaku Yamahata <isaku.yamahata@...el.com>
> > ---
> >
>
> [snip]
>
> > +
> > +int tdx_offline_cpu(void)
> > +{
> > + int curr_cpu = smp_processor_id();
> > + cpumask_var_t packages;
> > + int ret = 0;
> > + int i;
> > +
> > + if (!atomic_read(&nr_configured_hkid))
> > + return 0;
>
> As mentioned above, I think it also worth to add some comment here. When people
> are trying to understand some code, I think mostly they are just going to look
> at the code itself, but won't use 'git blame' to dig out the entire changelog to
> understand some code.
Makes sense. Added a comment.
--
Isaku Yamahata <isaku.yamahata@...il.com>
Powered by blists - more mailing lists