All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jue Wang <juew@google.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Add support for CMCI and UCNA.
Date: Tue, 12 Apr 2022 18:19:40 +0000	[thread overview]
Message-ID: <YlXCvEevoCZPj9Ba@google.com> (raw)
In-Reply-To: <390f6cd9-1757-b83c-ab97-5a991559e998@redhat.com>

On Tue, Apr 12, 2022, Paolo Bonzini wrote:
> On 4/11/22 21:08, Sean Christopherson wrote:
> > > +			if (!(mcg_cap & MCG_CMCI_P) &&
> > > +			    (data || !msr_info->host_initiated))
> > This looks wrong, userspace should either be able to write the MSR or not, '0'
> > isn't special.  Unless there's a danger to KVM, which I don't think there is,
> > userspace should be allowed to ignore architectural restrictions, i.e. bypass
> > the MCG_CMCI_P check, so that KVM doesn't create an unnecessary dependency between
> > ioctls.  I.e. this should be:
> > 
> > 		if (!(mcg_cap & MCG_CMCI_P) && !msr_info->host_initiated)
> > 			return 1;
> > 
> 
> This is somewhat dangerous as it complicates (or removes) the invariants
> that other code can rely on.  Thus, usually, only the default value is
> allowed for KVM_SET_MSR.

Heh, I don't know if "usually" is the right word, that implies KVM is consistent
enough to have a simple majority for any behavior, whatever that behavior may be :-)

Anyways, on second look, I agree that KVM should require that userspace first enable
CMCI via mcg_cap.  I thought that vcpu->arch.mcg_cap could be written via the MSR
interface, i.e. via userspace writes to MSR_IA32_MCG_CAP, and could create dependencies
within KVM_SET_MSRS.  But KVM only allows reading the MSR.

  reply	other threads:[~2022-04-12 18:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23 18:28 [PATCH] KVM: x86: Add support for CMCI and UCNA Jue Wang
2022-04-10 16:56 ` Jue Wang
2022-04-11 19:08 ` Sean Christopherson
2022-04-12 14:22   ` Jue Wang
2022-04-12 14:29     ` Jue Wang
2022-04-12 16:57       ` Sean Christopherson
2022-04-12 16:54     ` Sean Christopherson
2022-04-12 17:44   ` Paolo Bonzini
2022-04-12 18:19     ` Sean Christopherson [this message]
2022-04-12 19:52       ` Jue Wang

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=YlXCvEevoCZPj9Ba@google.com \
    --to=seanjc@google.com \
    --cc=juew@google.com \
    --cc=kvm@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.