From: Paolo Bonzini <pbonzini@redhat.com>
To: Oliver Upton <oupton@google.com>
Cc: kvm@vger.kernel.org, Sean Christopherson <seanjc@google.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 v4 1/8] KVM: nVMX: Keep KVM updates to BNDCFGS ctrl bits across MSR write
Date: Wed, 2 Mar 2022 22:22:43 +0100 [thread overview]
Message-ID: <4d4606f4-dbc9-d3a4-929e-0ea07182054c@redhat.com> (raw)
In-Reply-To: <Yh/Y3E4NTfSa4I/g@google.com>
On 3/2/22 21:51, Oliver Upton wrote:
> On Wed, Mar 02, 2022 at 01:21:23PM +0100, Paolo Bonzini wrote:
>> On 3/1/22 19:43, Oliver Upton wrote:
>>> Right, a 1-setting of '{load,clear} IA32_BNDCFGS' should really be the
>>> responsibility of userspace. My issue is that the commit message in
>>> commit 5f76f6f5ff96 ("KVM: nVMX: Do not expose MPX VMX controls when
>>> guest MPX disabled") suggests that userspace can expect these bits to be
>>> configured based on guest CPUID. Furthermore, before commit aedbaf4f6afd
>>> ("KVM: x86: Extract kvm_update_cpuid_runtime() from
>>> kvm_update_cpuid()"), if userspace clears these bits, KVM will continue
>>> to set them based on CPUID.
>>>
>>> What is the userspace expectation here? If we are saying that changes to
>>> IA32_VMX_TRUE_{ENTRY,EXIT}_CTLS after userspace writes these MSRs is a
>>> bug, then I agree aedbaf4f6afd is in fact a bugfix. But, the commit
>>> message in 5f76f6f5ff96 seems to indicate that userspace wants KVM to
>>> configure these bits based on guest CPUID.
>>
>> Yes, but I think it's reasonable that userspace wants to override them. It
>> has to do that after KVM_SET_CPUID2, but that's okay too.
>>
>
> In that case, I can rework the tests at the end of this series to ensure
> userspace's ability to override w/o a quirk. Sorry for the toil,
> aedbaf4f6afd caused some breakage for us internally, but really is just
> a userspace bug.
How did vanadium break?
Paolo
> Is it possible to pick up patch 4/8 "KVM: x86: Introduce
> KVM_CAP_DISABLE_QUIRKS2" independent of the rest of this series?
next prev parent reply other threads:[~2022-03-02 21:22 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 6:03 [PATCH v4 0/8] KVM: x86: VMX ctrl MSR + KVM quirk fixes Oliver Upton
2022-03-01 6:03 ` [PATCH v4 1/8] KVM: nVMX: Keep KVM updates to BNDCFGS ctrl bits across MSR write Oliver Upton
2022-03-01 18:00 ` Paolo Bonzini
2022-03-01 18:43 ` Oliver Upton
2022-03-02 12:21 ` Paolo Bonzini
2022-03-02 20:51 ` Oliver Upton
2022-03-02 21:22 ` Paolo Bonzini [this message]
2022-03-02 21:54 ` Oliver Upton
2022-03-03 1:43 ` Sean Christopherson
2022-03-03 6:29 ` Paolo Bonzini
2022-03-03 16:15 ` Sean Christopherson
2022-03-03 21:44 ` Jim Mattson
2022-03-03 23:44 ` Sean Christopherson
2022-03-04 15:50 ` Paolo Bonzini
2022-04-07 0:26 ` Sean Christopherson
2022-04-07 0:29 ` Oliver Upton
2022-04-07 0:32 ` Oliver Upton
2022-04-07 0:34 ` Sean Christopherson
2022-05-27 16:55 ` Sean Christopherson
2022-03-01 6:03 ` [PATCH v4 2/8] KVM: nVMX: Keep KVM updates to PERF_GLOBAL_CTRL " Oliver Upton
2022-03-01 18:01 ` Paolo Bonzini
2022-04-07 0:21 ` Sean Christopherson
2022-03-01 6:03 ` [PATCH v4 3/8] KVM: nVMX: Drop nested_vmx_pmu_refresh() Oliver Upton
2022-03-01 6:03 ` [PATCH v4 4/8] KVM: x86: Introduce KVM_CAP_DISABLE_QUIRKS2 Oliver Upton
2022-03-09 16:01 ` Paolo Bonzini
2022-03-01 6:03 ` [PATCH v4 5/8] KVM: nVMX: Add a quirk for KVM tweaks to VMX control MSRs Oliver Upton
2022-04-07 0:28 ` Sean Christopherson
2022-03-01 6:03 ` [PATCH v4 6/8] selftests: KVM: Separate static alloc from KVM_GET_SUPPORTED_CPUID call Oliver Upton
2022-03-01 6:03 ` [PATCH v4 7/8] selftests: KVM: Add test for PERF_GLOBAL_CTRL VMX control MSR bits Oliver Upton
2022-03-01 16:59 ` David Dunn
2022-03-01 6:03 ` [PATCH v4 8/8] selftests: KVM: Add test for BNDCFGS " Oliver Upton
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=4d4606f4-dbc9-d3a4-929e-0ea07182054c@redhat.com \
--to=pbonzini@redhat.com \
--cc=daviddunn@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=oupton@google.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.