All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] KVM: x86: Explicitly zero kvm_caps during vendor module load
Date: Wed, 24 Apr 2024 08:33:43 -0700	[thread overview]
Message-ID: <ZikmVzsvV-tt_pSs@google.com> (raw)
In-Reply-To: <8e3ad8fa55a26d8726ef0b68e40f59cbcdac1f6c.camel@intel.com>

On Wed, Apr 24, 2024, Kai Huang wrote:
> On Tue, 2024-04-23 at 09:53 -0700, Sean Christopherson wrote:
> > Zero out all of kvm_caps when loading a new vendor module to ensure that
> > KVM can't inadvertently rely on global initialization of a field, and add
> > a comment above the definition of kvm_caps to call out that all fields
> > needs to be explicitly computed during vendor module load.
> > 
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kvm/x86.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 44ce187bad89..8f3979d5fc80 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -92,6 +92,11 @@
> >  #define MAX_IO_MSRS 256
> >  #define KVM_MAX_MCE_BANKS 32
> >  
> > +/*
> > + * Note, kvm_caps fields should *never* have default values, all fields must be
> > + * recomputed from scratch during vendor module load, e.g. to account for a
> > + * vendor module being reloaded with different module parameters.
> > + */
> >  struct kvm_caps kvm_caps __read_mostly;
> >  EXPORT_SYMBOL_GPL(kvm_caps);
> >  
> > @@ -9755,6 +9760,8 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
> >  		return -EIO;
> >  	}
> >  
> > +	memset(&kvm_caps, 0, sizeof(kvm_caps));
> > +
> >  	x86_emulator_cache = kvm_alloc_emulator_cache();
> >  	if (!x86_emulator_cache) {
> >  		pr_err("failed to allocate cache for x86 emulator\n");
> 
> Why do the memset() here particularly?

So that it happens as early as possible, e.g. in case kvm_mmu_vendor_module_init()
or some other function comes along and modifies kvm_caps.

> Isn't it better to put ...
> 
> 	memset(&kvm_caps, 0, sizeof(kvm_caps));
> 	kvm_caps.supported_vm_types = BIT(KVM_X86_DEFAULT_VM);
> 	kvm_caps.supported_mce_cap = MCG_CTL_P | MCG_SER_P;
> 
> ... together so it can be easily seen?
> 
> We can even have a helper to do above to "reset kvm_caps to default
> values" I think.

Hmm, I don't think a helper is necessary, but I do agree that having all of the
explicit initialization in one place would be better.  The alternative would be
to use |= for BIT(KVM_X86_DEFAULT_VM), and MCG_CTL_P | MCG_SER_P, but I don't
think that would be an improvement.  I'll tweak the first two patches to set the
hardcoded caps earlier.

The main reason I don't want to add a helper is that coming up with a name would
be tricky.  E.g. "kvm_reset_caps()" isn't a great fit because the caps are "reset"
throughout module loading.  "kvm_set_default_caps()" kinda fits, but they aren't
so much that they are KVM's defaults, rather they are the caps that KVM can always
support regardless of hardware support, e.g. supported_xcr0 isn't optional, it
just depends on hardware.

  reply	other threads:[~2024-04-24 15:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-23 16:53 [PATCH 0/3] KVM: x86: Fix supported VM_TYPES caps Sean Christopherson
2024-04-23 16:53 ` [PATCH 1/3] KVM: x86: Fully re-initialize supported_vm_types on vendor module load Sean Christopherson
2024-04-23 16:53 ` [PATCH 2/3] KVM: x86: Fully re-initialize supported_mce_cap " Sean Christopherson
2024-04-23 16:53 ` [PATCH 3/3] KVM: x86: Explicitly zero kvm_caps during " Sean Christopherson
2024-04-24  3:25   ` Huang, Kai
2024-04-24 15:33     ` Sean Christopherson [this message]
2024-04-25 10:07       ` Huang, Kai
2024-04-25 13:43 ` [PATCH 0/3] KVM: x86: Fix supported VM_TYPES caps Xiaoyao Li
2024-04-25 14:30   ` Sean Christopherson
2024-04-26  1:17     ` Huang, Kai
2024-04-26 15:47       ` Sean Christopherson
2024-04-29  2:45         ` Huang, Kai
2024-04-29 15:56           ` Sean Christopherson
2024-05-07 17:20             ` Paolo Bonzini
2024-05-07 17:08 ` Paolo Bonzini
2024-05-10 14:50 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZikmVzsvV-tt_pSs@google.com \
    --to=seanjc@google.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.