From: Paolo Bonzini <pbonzini@redhat.com>
To: Jim Mattson <jmattson@google.com>, Arbel Moshe <arbel.moshe@oracle.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
"kvm list" <kvm@vger.kernel.org>,
"Wanpeng Li" <wanpeng.li@hotmail.com>,
"Idan Brown" <idan.brown@oracle.com>,
"Liran Alon" <liran.alon@oracle.com>,
"Krish Sadhukhan" <krish.sadhukhan@oracle.com>
Subject: Re: [PATCH v2 3/3] KVM: nVMX: Fix nested APICv Secondary CPU Controls when apicv disabled
Date: Fri, 24 Nov 2017 00:57:20 +0100 [thread overview]
Message-ID: <98a4137b-fa4e-5a6c-d503-bfd31c6cae8d@redhat.com> (raw)
In-Reply-To: <CALMp9eTAVW2wyNGS3H0JaKs2wZXaaenNE1HSEcWtEQdyV3AMoA@mail.gmail.com>
On 22/11/2017 18:56, Jim Mattson wrote:
> I don't
> believe that L1 has to have lapic_in_kernel() for L0 to use the APICv
> features of the hardware when running L2.
Without lapic_in_kernel() the guest doesn't have the X2APIC CPUID bit
and x2APIC MSRs (at least on upstream KVM, don't know if Google's
userspace MSR patches can do it).
Therefore it makes no sense to allow the "virtualize APIC accesses"
control for L1, as the control implies the availability of the MSRs.
> I'm also not sure that
> Hyper-V SynIC activation for L1 has any bearing on whether or not L0
> can use the APICv features of the hardware when running L2.
I agree with this.
Paolo
next prev parent reply other threads:[~2017-11-23 23:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-22 10:23 [PATCH v2 0/3] KVM: nVMX: Do not expose APICv to L1 if disabled on L0 Arbel Moshe
2017-11-22 10:23 ` [PATCH v2 1/3] KVM: nVMX: Refresh APICv secondary exec controls by re-calculating all of them Arbel Moshe
2017-11-22 17:17 ` Jim Mattson
2017-11-22 18:08 ` Jim Mattson
2017-11-23 23:51 ` Paolo Bonzini
2017-11-22 10:23 ` [PATCH v2 2/3] KVM: nVMX: Update nested MSRs in case APICv refreshing Arbel Moshe
2017-11-22 18:04 ` Jim Mattson
2017-11-23 23:54 ` Paolo Bonzini
2017-11-22 10:23 ` [PATCH v2 3/3] KVM: nVMX: Fix nested APICv Secondary CPU Controls when apicv disabled Arbel Moshe
2017-11-22 17:56 ` Jim Mattson
2017-11-23 23:57 ` Paolo Bonzini [this message]
2017-11-27 17:14 ` Jim Mattson
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=98a4137b-fa4e-5a6c-d503-bfd31c6cae8d@redhat.com \
--to=pbonzini@redhat.com \
--cc=arbel.moshe@oracle.com \
--cc=idan.brown@oracle.com \
--cc=jmattson@google.com \
--cc=krish.sadhukhan@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=rkrcmar@redhat.com \
--cc=wanpeng.li@hotmail.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