[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZkI94l9rcfBSH0pV@google.com>
Date: Mon, 13 May 2024 09:20:50 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Kai Huang <kai.huang@...el.com>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] KVM: Rename functions related to enabling
virtualization hardware
On Mon, May 13, 2024, Kai Huang wrote:
> On Thu, 2024-04-25 at 16:39 -0700, Sean Christopherson wrote:
> > Rename the various functions that enable virtualization to prepare for
> > upcoming changes, and to clean up artifacts of KVM's previous behavior,
> > which required manually juggling locks around kvm_usage_count.
> >
> > Drop the "nolock" qualifier from per-CPU functions now that there are no
> > "nolock" implementations of the "all" variants, i.e. now that calling a
> > non-nolock function from a nolock function isn't confusing (unlike this
> > sentence).
> >
> > Drop "all" from the outer helpers as they no longer manually iterate
> > over all CPUs, and because it might not be obvious what "all" refers to.
> > Instead, use double-underscores to communicate that the per-CPU functions
> > are helpers to the outer APIs.
> >
>
> I kinda prefer
>
> cpu_enable_virtualization();
>
> instead of
>
> __kvm_enable_virtualization();
>
> But obviously not a strong opinion :-)
I feel quite strongly about using __kvm_enable_virtualization(). While "cpu" is
very precise, to me it implies that the code lives outside of KVM and isn't purely
a helper for kvm_enable_virtualization().
Powered by blists - more mailing lists