All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	David Dunn <daviddunn@google.com>
Subject: Re: [PATCH] KVM: x86: Introduce KVM_CAP_DISABLE_QUIRKS2
Date: Mon, 28 Feb 2022 18:00:42 +0000	[thread overview]
Message-ID: <Yh0NyuuzIymt9mgt@google.com> (raw)
In-Reply-To: <Yhz5dRH/7gF45Zee@google.com>

On Mon, Feb 28, 2022 at 04:33:57PM +0000, Sean Christopherson wrote:
> On Sat, Feb 26, 2022, Oliver Upton wrote:
> > KVM_CAP_DISABLE_QUIRKS is irrevocably broken. The capability does not
> > advertise the set of quirks which may be disabled to userspace, so it is
> > impossible to predict the behavior of KVM. Worse yet,
> > KVM_CAP_DISABLE_QUIRKS will tolerate any value for cap->args[0], meaning
> > it fails to reject attempts to set invalid quirk bits.
> 
> FWIW, we do have a way out without adding another capability.  The 'flags' field
> is enforced for all capabilities, we could use a bit there to add "v2" functionality.
> Userspace can assume KVM_QUIRK_ENFORCE_QUIRKS is allowed if the return from probing
> the capability is >1.
> 
> It's gross and forced, just an idea if we want to avoid yet another cap.

I had considered this before sending out v1, but was concerned if a
userspace didn't correctly handle a return value >1 from
KVM_CHECK_EXTENSION. Turns out, I can't even find any evidence of the
KVM_CAP_DISABLE_QUIRKS used by userspace. I spot checked QEMU, kvmtool,
and a couple of the rusty ones.

The only other thing that comes to mind is it's a bit gross for userspace
to do a graceful fallback if KVM_QUIRK_ENFORCE_QUIRKS isn't valid, since
most userspace would just error out on -EINVAL. At least with a new cap
userspace could follow a somewhat standardized way to discover if the
kernel supports enforced quirks.

[...]

> > +7.30 KVM_CAP_DISABLE_QUIRKS2
> > +----------------------------
> > +
> > +:Capability: KVM_CAP_DISABLE_QUIRKS2
> > +:Parameters: args[0] - set of KVM quirks to disable
> > +:Architectures: x86
> > +:Type: vm
> > +
> > +This capability, if enabled, will cause KVM to disable some behavior
> > +quirks.
> > +
> > +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of
> > +quirks that can be disabled in KVM.
> > +
> > +The argument to KVM_ENABLE_CAP for this capability is a bitmask of
> > +quirks to disable, and must be a subset of the bitmask returned by
> > +KVM_CHECK_EXTENSION.
> > +
> > +The valid bits in cap.args[0] are:
> > +
> > +=================================== ============================================
> > + KVM_X86_QUIRK_LINT0_ENABLED        By default, the reset value for the LVT
> 
> LINT0_REEANBLED.

Oops. Thanks!

--
Oliver

  reply	other threads:[~2022-02-28 18:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-26  0:21 [PATCH] KVM: x86: Introduce KVM_CAP_DISABLE_QUIRKS2 Oliver Upton
2022-02-26  0:22 ` Oliver Upton
2022-02-28 16:33 ` Sean Christopherson
2022-02-28 18:00   ` Oliver Upton [this message]
2022-02-28 18:22     ` Sean Christopherson

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=Yh0NyuuzIymt9mgt@google.com \
    --to=oupton@google.com \
    --cc=daviddunn@google.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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.