From: Sean Christopherson <seanjc@google.com>
To: Zeng Guang <guang.zeng@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, Dave Hansen <dave.hansen@linux.intel.com>,
Tony Luck <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>,
Kai Huang <kai.huang@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Robert Hu <robert.hu@intel.com>, Gao Chao <chao.gao@intel.com>
Subject: Re: [PATCH v7 5/8] KVM: x86: Add support for vICR APIC-write VM-Exits in x2APIC mode
Date: Thu, 31 Mar 2022 23:07:30 +0000 [thread overview]
Message-ID: <YkY0MvAIPiISfk4u@google.com> (raw)
In-Reply-To: <20220304080725.18135-6-guang.zeng@intel.com>
On Fri, Mar 04, 2022, Zeng Guang wrote:
> Upcoming Intel CPUs will support virtual x2APIC MSR writes to the vICR,
> i.e. will trap and generate an APIC-write VM-Exit instead of intercepting
> the WRMSR. Add support for handling "nodecode" x2APIC writes, which
> were previously impossible.
>
> Note, x2APIC MSR writes are 64 bits wide.
>
> Signed-off-by: Zeng Guang <guang.zeng@intel.com>
> ---
> arch/x86/kvm/lapic.c | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 629c116b0d3e..22929b5b3f9b 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -67,6 +67,7 @@ static bool lapic_timer_advance_dynamic __read_mostly;
> #define LAPIC_TIMER_ADVANCE_NS_MAX 5000
> /* step-by-step approximation to mitigate fluctuation */
> #define LAPIC_TIMER_ADVANCE_ADJUST_STEP 8
> +static int kvm_lapic_msr_read(struct kvm_lapic *apic, u32 reg, u64 *data);
>
> static inline void __kvm_lapic_set_reg(char *regs, int reg_off, u32 val)
> {
> @@ -2227,10 +2228,25 @@ EXPORT_SYMBOL_GPL(kvm_lapic_set_eoi);
> /* emulate APIC access in a trap manner */
> void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset)
> {
> - u32 val = kvm_lapic_get_reg(vcpu->arch.apic, offset);
> + struct kvm_lapic *apic = vcpu->arch.apic;
> + u64 val;
> +
> + if (apic_x2apic_mode(apic)) {
> + /*
> + * When guest APIC is in x2APIC mode and IPI virtualization
> + * is enabled, accessing APIC_ICR may cause trap-like VM-exit
> + * on Intel hardware. Other offsets are not possible.
> + */
> + if (WARN_ON_ONCE(offset != APIC_ICR))
> + return;
>
> - /* TODO: optimize to just emulate side effect w/o one more write */
> - kvm_lapic_reg_write(vcpu->arch.apic, offset, val);
> + kvm_lapic_msr_read(apic, offset, &val);
> + kvm_apic_send_ipi(apic, (u32)val, (u32)(val >> 32));
This needs to clear the APIC_ICR_BUSY bit. It'd also be nice to trace this write.
The easiest thing is to use kvm_x2apic_icr_write(). Kinda silly as it'll generate
an extra write, but on the plus side the TODO comment doesn't have to move :-D
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index c4c3155d98db..58bf296ee313 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2230,6 +2230,7 @@ void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset)
struct kvm_lapic *apic = vcpu->arch.apic;
u64 val;
+ /* TODO: optimize to just emulate side effect w/o one more write */
if (apic_x2apic_mode(apic)) {
/*
* When guest APIC is in x2APIC mode and IPI virtualization
@@ -2240,10 +2241,9 @@ void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset)
return;
kvm_lapic_msr_read(apic, offset, &val);
- kvm_apic_send_ipi(apic, (u32)val, (u32)(val >> 32));
+ kvm_x2apic_icr_write(apic, val);
} else {
val = kvm_lapic_get_reg(apic, offset);
- /* TODO: optimize to just emulate side effect w/o one more write */
kvm_lapic_reg_write(apic, offset, (u32)val);
}
}
> + } else {
> + val = kvm_lapic_get_reg(apic, offset);
> + /* TODO: optimize to just emulate side effect w/o one more write */
> + kvm_lapic_reg_write(apic, offset, (u32)val);
> + }
> }
> EXPORT_SYMBOL_GPL(kvm_apic_write_nodecode);
>
> --
> 2.27.0
>
next prev parent reply other threads:[~2022-03-31 23:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-04 8:07 [PATCH v7 0/8] IPI virtualization support for VM Zeng Guang
2022-03-04 8:07 ` [PATCH v7 1/8] x86/cpu: Add new VMX feature, Tertiary VM-Execution control Zeng Guang
2022-03-04 8:07 ` [PATCH v7 2/8] KVM: VMX: Extend BUILD_CONTROLS_SHADOW macro to support 64-bit variation Zeng Guang
2022-03-31 22:27 ` Sean Christopherson
2022-04-02 12:47 ` Zeng Guang
2022-03-04 8:07 ` [PATCH v7 3/8] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config Zeng Guang
2022-03-31 22:41 ` Sean Christopherson
2022-04-02 12:58 ` Zeng Guang
2022-03-04 8:07 ` [PATCH v7 4/8] KVM: VMX: dump_vmcs() reports tertiary_exec_control field as well Zeng Guang
2022-03-31 22:46 ` Sean Christopherson
2022-04-02 13:09 ` Zeng Guang
2022-03-04 8:07 ` [PATCH v7 5/8] KVM: x86: Add support for vICR APIC-write VM-Exits in x2APIC mode Zeng Guang
2022-03-31 23:07 ` Sean Christopherson [this message]
2022-04-02 13:33 ` Zeng Guang
2022-04-04 15:29 ` Sean Christopherson
2022-03-04 8:07 ` [PATCH v7 6/8] KVM: x86: lapic: don't allow to change APIC ID unconditionally Zeng Guang
2022-03-04 8:07 ` [PATCH v7 7/8] KVM: x86: Allow userspace set maximum VCPU id for VM Zeng Guang
2022-04-01 2:01 ` Sean Christopherson
2022-04-03 10:17 ` Zeng Guang
2022-04-04 17:25 ` Sean Christopherson
2022-03-04 8:07 ` [PATCH v7 8/8] KVM: VMX: enable IPI virtualization Zeng Guang
2022-04-01 2:37 ` Sean Christopherson
2022-04-03 14:38 ` Zeng Guang
2022-04-04 17:57 ` Sean Christopherson
2022-04-08 16:41 ` Zeng Guang
2022-04-15 14:35 ` Sean Christopherson
2022-03-18 8:15 ` [PATCH v7 0/8] IPI virtualization support for VM Zeng Guang
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=YkY0MvAIPiISfk4u@google.com \
--to=seanjc@google.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=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.