From: stsp <stsp2@yandex.ru>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: 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>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] KVM: x86: KVM_SET_SREGS.CR4 bug fixes and cleanup
Date: Fri, 9 Oct 2020 17:11:51 +0300 [thread overview]
Message-ID: <5dfa55f3-ecdf-9f8d-2d45-d2e6e54f2daa@yandex.ru> (raw)
In-Reply-To: <20201009040453.GA10744@linux.intel.com>
09.10.2020 07:04, Sean Christopherson пишет:
>> Hmm. But at least it was lying
>> similarly on AMD and Intel CPUs. :)
>> So I was able to reproduce the problems
>> myself.
>> Do you mean, any AMD tests are now useless, and we need to proceed with Intel
>> tests only?
> For anything VMXE related, yes.
What would be the expected behaviour
on Intel, if it is set? Any difference with AMD?
>> Then additional question.
>> On old Intel CPUs we needed to set VMXE in guest to make it to work in
>> nested-guest mode.
>> Is it still needed even with your patches?
>> Or the nested-guest mode will work now even on older Intel CPUs and KVM will
>> set VMXE for us itself, when needed?
> I'm struggling to even come up with a theory as to how setting VMXE from
> userspace would have impacted KVM with unrestricted_guest=n, let alone fixed
> anything.
>
> CR4.VMXE must always be 1 in _hardware_ when VMX is on, including when running
> the guest. But KVM forces vmcs.GUEST_CR4.VMXE=1 at all times, regardless of
> the guest's actual value (the guest sees a shadow value when it reads CR4).
>
> And unless I grossly misunderstand dosemu2, it's not doing anything related to
> nested virtualization, i.e. the stuffing VMXE=1 for the guest's shadow value
> should have absolutely zero impact.
>
> More than likely, VMXE was a red herring.
Yes, it was. :(
(as you can see from the end of the
github thread)
> Given that the reporter is also
> seeing the same bug on bare metal after moving to kernel 5.4, odds are good
> the issue is related to unrestricted_guest=n and has nothing to do with nVMX.
But we do not use unrestricted guest.
We use v86 under KVM.
The only other effect of setting VMXE
was clearing VME. Which shouldn't affect
anything either, right?
next prev parent reply other threads:[~2020-10-09 14:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 1:44 Sean Christopherson
2020-10-07 1:44 ` [PATCH 1/6] KVM: VMX: Drop guest CPUID check for VMXE in vmx_set_cr4() Sean Christopherson
2020-10-07 1:44 ` [PATCH 2/6] KVM: VMX: Drop explicit 'nested' check from vmx_set_cr4() Sean Christopherson
2020-10-07 1:44 ` [PATCH 3/6] KVM: SVM: Drop VMXE check from svm_set_cr4() Sean Christopherson
2020-10-07 1:44 ` [PATCH 4/6] KVM: x86: Move vendor CR4 validity check to dedicated kvm_x86_ops hook Sean Christopherson
2020-10-07 1:44 ` [PATCH 5/6] KVM: x86: Return bool instead of int for CR4 and SREGS validity checks Sean Christopherson
2020-10-07 1:44 ` [PATCH 6/6] KVM: selftests: Verify supported CR4 bits can be set before KVM_SET_CPUID2 Sean Christopherson
2020-10-08 16:00 ` [PATCH 0/6] KVM: x86: KVM_SET_SREGS.CR4 bug fixes and cleanup stsp
2020-10-08 17:59 ` Sean Christopherson
2020-10-08 18:18 ` stsp
2020-10-09 4:04 ` Sean Christopherson
2020-10-09 14:11 ` stsp [this message]
2020-10-09 15:30 ` Sean Christopherson
2020-10-09 15:48 ` stsp
2020-10-09 16:11 ` Sean Christopherson
2020-12-07 11:19 ` KVM_SET_CPUID doesn't check supported bits (was Re: [PATCH 0/6] KVM: x86: KVM_SET_SREGS.CR4 bug fixes and cleanup) stsp
2020-12-07 11:24 ` stsp
2020-12-07 11:29 ` Paolo Bonzini
2020-12-07 11:47 ` stsp
[not found] ` <CABgObfYS57_ez-t=eu9+3S2bhSXC_9DTj=64Sna2jnYEMYo2Ag@mail.gmail.com>
2020-12-07 14:03 ` stsp
[not found] ` <CABgObfb_4r=k_qakd+48hPar8rzc-P50+dgdoYvQaL2H-po6+g@mail.gmail.com>
2020-12-07 14:29 ` stsp
[not found] ` <CABgObfYN7Okdt+YfHtsd3M_00iuWf=UyKPmbQhhYBhoiMtdXuw@mail.gmail.com>
2020-12-07 14:41 ` stsp
2020-12-07 23:59 ` Jim Mattson
2020-11-13 11:36 ` [PATCH 0/6] KVM: x86: KVM_SET_SREGS.CR4 bug fixes and cleanup 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=5dfa55f3-ecdf-9f8d-2d45-d2e6e54f2daa@yandex.ru \
--to=stsp2@yandex.ru \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®