All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Chao Gao <chao.gao@intel.com>
Cc: Zeng Guang <guang.zeng@intel.com>,
	Sean Christopherson <seanjc@google.com>,
	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" <kvm@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hu, Robert" <robert.hu@intel.com>
Subject: Re: [PATCH v6 6/9] KVM: x86: lapic: don't allow to change APIC ID unconditionally
Date: Tue, 15 Mar 2022 17:30:32 +0200	[thread overview]
Message-ID: <c903e82ed2a1e98f66910c35b5aabdcf56e08e72.camel@redhat.com> (raw)
In-Reply-To: <20220315151033.GA6038@gao-cwp>

On Tue, 2022-03-15 at 23:10 +0800, Chao Gao wrote:
> On Sun, Mar 13, 2022 at 05:09:08PM +0200, Maxim Levitsky wrote:
> > > > > This won't work with nested AVIC - we can't just inhibit a nested guest using its own AVIC,
> > > > > because migration happens.
> > > > 
> > > > I mean because host decided to change its apic id, which it can in theory do any time,
> > > > even after the nested guest has started. Seriously, the only reason guest has to change apic id,
> > > > is to try to exploit some security hole.
> > > 
> > > Hi
> > > 
> > > Thanks for the information.  
> > > 
> > > IIUC, you mean KVM applies APICv inhibition only to L1 VM, leaving APICv
> > > enabled for L2 VM. Shouldn't KVM disable APICv for L2 VM in this case?
> > > It looks like a generic issue in dynamically toggling APICv scheme,
> > > e.g., qemu can set KVM_GUESTDBG_BLOCKIRQ after nested guest has started.
> > > 
> > 
> > That is the problem - you can't disable it for L2, unless you are willing to emulate it in software.
> > Or in other words, when nested guest uses a hardware feature, you can't at some point say to it:
> > sorry buddy - hardware feature disappeared.
> 
> Hi Maxim,
> 
> I may miss something. When reading Sean's APICv inhibition cleanups, I
> find AVIC is disabled for L1 when nested is enabled (SVM is advertised
> to L1). Then, I think the new inhibition introduced for changed xAPIC ID
> shouldn't be a problem for L2 VM. Or, you plan to remove
> APICV_INHIBIT_REASON_NESTED and expose AVIC to L1?

Yep, I  have a patch for this ( which I hope to be accepted really soon
(KVM: x86: SVM: allow AVIC to co-exist with a nested guest running)
 
I also implemented working support for nested AVIC, which includes support for IPI without vm exits
between L2's vCPUs. I had sent an RFC for that.
 
With all patches applied both L1 and L2 switch hands on AVIC, L1's avic is inhibited
(only locally) on the vCPU which runs nested, and while it runs nested, L2 uses AVIC
to target other vCPUs which also run nested.
 
I and Paolo talked about this, and we reached a very promising conclusion.

I will add new KVM cap, say KVM_CAP_READ_ONLY_APIC, which userspace will set
prior to creating a vCPU, and which will make APIC ID fully readonly when set.
 
As a bonus, if you don't object, I will also make this cap, make APIC base read-only,
since this feature is also broken in kvm, optional in x86 spec, and not really
used by guests just like writable apic id.

I hope to have patches in day or two for this.
 
When this cap is not set, it is fair to disable both IPIv, my nested AVIC,
or even better inhibit AVIC completely, including any nested support.
 
Best regards,
	Maxim Levitsky

> 
> svm_vcpu_after_set_cpuid:
>                 /*
>                  * Currently, AVIC does not work with nested virtualization.
>                  * So, we disable AVIC when cpuid for SVM is set in the L1 guest.
>                  */
>                 if (nested && guest_cpuid_has(vcpu, X86_FEATURE_SVM))
>                         kvm_request_apicv_update(vcpu->kvm, false,
>                                                  APICV_INHIBIT_REASON_NESTED);
> 



  reply	other threads:[~2022-03-15 15:30 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25  8:22 [PATCH v6 0/9] IPI virtualization support for VM Zeng Guang
2022-02-25  8:22 ` [PATCH v6 1/9] x86/cpu: Add new VMX feature, Tertiary VM-Execution control Zeng Guang
2022-02-25 14:09   ` Maxim Levitsky
2022-02-25  8:22 ` [PATCH v6 2/9] KVM: VMX: Extend BUILD_CONTROLS_SHADOW macro to support 64-bit variation Zeng Guang
2022-02-25 14:24   ` Maxim Levitsky
2022-02-25  8:22 ` [PATCH v6 3/9] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config Zeng Guang
2022-02-25 14:30   ` Maxim Levitsky
2022-02-25  8:22 ` [PATCH v6 4/9] KVM: VMX: dump_vmcs() reports tertiary_exec_control field as well Zeng Guang
2022-02-25 14:31   ` Maxim Levitsky
2022-02-25  8:22 ` [PATCH v6 5/9] KVM: x86: Add support for vICR APIC-write VM-Exits in x2APIC mode Zeng Guang
2022-02-25 14:44   ` Maxim Levitsky
2022-02-25 15:29     ` Chao Gao
2022-02-25  8:22 ` [PATCH v6 6/9] KVM: x86: lapic: don't allow to change APIC ID unconditionally Zeng Guang
2022-02-25 14:46   ` Maxim Levitsky
2022-02-25 14:56     ` David Woodhouse
2022-02-25 15:11       ` Maxim Levitsky
2022-02-25 15:42         ` David Woodhouse
2022-02-25 16:12           ` Maxim Levitsky
2022-03-01  8:03     ` Chao Gao
2022-03-08 23:04   ` Sean Christopherson
2022-03-09  5:21     ` Chao Gao
2022-03-09  6:01       ` Sean Christopherson
2022-03-09 12:59         ` Maxim Levitsky
2022-03-11  4:26           ` Sean Christopherson
     [not found]             ` <29c76393-4884-94a8-f224-08d313b73f71@intel.com>
2022-03-13  9:19               ` Maxim Levitsky
2022-03-13 10:59                 ` Maxim Levitsky
2022-03-13 13:53                   ` Chao Gao
2022-03-13 15:09                     ` Maxim Levitsky
2022-03-14  4:09                       ` Chao Gao
2022-03-15 15:10                       ` Chao Gao
2022-03-15 15:30                         ` Maxim Levitsky [this message]
2022-03-16 11:50                           ` Chao Gao
2022-02-25  8:22 ` [PATCH v6 7/9] KVM: VMX: enable IPI virtualization Zeng Guang
2022-02-25 17:19   ` Maxim Levitsky
2022-03-01  9:21     ` Chao Gao
2022-03-02  6:45       ` Chao Gao
2022-02-25  8:22 ` [PATCH v6 8/9] KVM: x86: Allow userspace set maximum VCPU id for VM Zeng Guang
2022-02-25 17:22   ` Maxim Levitsky
2022-02-25  8:22 ` [PATCH v6 9/9] KVM: VMX: Optimize memory allocation for PID-pointer table Zeng Guang
2022-02-25 17:29   ` Maxim Levitsky
2022-03-01  9:23     ` Chao Gao

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=c903e82ed2a1e98f66910c35b5aabdcf56e08e72.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=guang.zeng@intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jethro@fortanix.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kai.huang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /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.