From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] kvm: x86: remove vmx_vm_has_apicv() outside of hwapic_isr_update()
Date: Mon, 22 Dec 2014 17:01:13 +0800 [thread overview]
Message-ID: <5497DDD9.4000300@intel.com> (raw)
In-Reply-To: <5494081A.7020601@redhat.com>
On 2014/12/19 19:12, Paolo Bonzini wrote:
>
>
> On 19/12/2014 03:32, Chen, Tiejun wrote:
>>
>> Are you saying something below?
>>
>> if (enable_apicv)
>> ...
>> else {
>> kvm_x86_ops->hwapic_irr_update = NULL;
>
> Yes.
>
>> But this means we have to revise hadware_setup() to get 'kvm' inside,
>
> This would not even be possible, since hardware_setup() is only called once.
Yeah.
>
> However, for the only caller of hwapic_isr_update (but presumably all of
> them, as is the case for hwapic_irr_update), you already know that
There are two other callers to hwapic_isr_update(), apic_set_isr() and
apic_clear_isr(), but I think they still work here.
> irqchip_in_kernel(kvm) is true. You are in kvm_apic_post_state_restore,
> which takes a kvm_lapic_state, and no lapic exists if
> !irqchip_in_kernel(kvm).
>
> (Yes, irqchip_in_kernel) is a bit weird and tests pic_irqchip(kvm)
> instead, but it's the same. It tests pic_irqchip(kvm) only because the
> LAPIC is per-cpu and irqchip_in_kernel takes a struct kvm).
>
> So it's possible to NULL out hwapic_isr_update in hardware_setup. It
> simply shouldn't happen that you call hwapic_isr_update without the
> in-kernel irqchip. The kernel knows nothing about ISR/IRR without the
> in-kernel irqchip.
Thanks for your kind elaboration which always benefits me.
What about this revision as follows?
kvm: x86: vmx: NULL out hwapic_isr_update() in case of !enable_apicv
In most cases calling hwapic_isr_update(), we always check if
kvm_apic_vid_enabled() == 1, but actually,
kvm_apic_vid_enabled()
-> kvm_x86_ops->vm_has_apicv()
-> vmx_vm_has_apicv() or '0' in svm case
-> return enable_apicv && irqchip_in_kernel(kvm)
So its a little cost to recall vmx_vm_has_apicv() inside
hwapic_isr_update(), here just NULL out hwapic_isr_update() in
case of !enable_apicv inside hardware_setup() then make all
related stuffs follow this. Note we don't check this under that
condition of irqchip_in_kernel() since we should make sure
definitely any caller don't work without in-kernel irqchip.
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
arch/x86/kvm/lapic.c | 7 ++++---
arch/x86/kvm/vmx.c | 4 +---
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 4f0c0b9..eb4cd5e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -402,7 +402,7 @@ static inline void apic_set_isr(int vec, struct
kvm_lapic *apic)
* because the processor can modify ISR under the hood. Instead
* just set SVI.
*/
- if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
+ if (unlikely(kvm_x86_ops->hwapic_isr_update))
kvm_x86_ops->hwapic_isr_update(vcpu->kvm, vec);
else {
++apic->isr_count;
@@ -450,7 +450,7 @@ static inline void apic_clear_isr(int vec, struct
kvm_lapic *apic)
* on the other hand isr_count and highest_isr_cache are unused
* and must be left alone.
*/
- if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
+ if (unlikely(kvm_x86_ops->hwapic_isr_update))
kvm_x86_ops->hwapic_isr_update(vcpu->kvm,
apic_find_highest_isr(apic));
else {
@@ -1742,7 +1742,8 @@ void kvm_apic_post_state_restore(struct kvm_vcpu
*vcpu,
if (kvm_x86_ops->hwapic_irr_update)
kvm_x86_ops->hwapic_irr_update(vcpu,
apic_find_highest_irr(apic));
- kvm_x86_ops->hwapic_isr_update(vcpu->kvm,
apic_find_highest_isr(apic));
+ if (kvm_x86_ops->hwapic_isr_update)
+ kvm_x86_ops->hwapic_isr_update(vcpu->kvm,
apic_find_highest_isr(apic));
kvm_make_request(KVM_REQ_EVENT, vcpu);
kvm_rtc_eoi_tracking_restore_one(vcpu);
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 96c84a8..e378dff 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5895,6 +5895,7 @@ static __init int hardware_setup(void)
kvm_x86_ops->update_cr8_intercept = NULL;
else {
kvm_x86_ops->hwapic_irr_update = NULL;
+ kvm_x86_ops->hwapic_isr_update = NULL;
kvm_x86_ops->deliver_posted_interrupt = NULL;
kvm_x86_ops->sync_pir_to_irr = vmx_sync_pir_to_irr_dummy;
}
@@ -7471,9 +7472,6 @@ static void vmx_hwapic_isr_update(struct kvm *kvm,
int isr)
u16 status;
u8 old;
- if (!vmx_vm_has_apicv(kvm))
- return;
-
if (isr == -1)
isr = 0;
--
1.9.1
I can send out as a patch if we have on any objections.
Thanks
Tiejun
next prev parent reply other threads:[~2014-12-22 9:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 9:28 [PATCH] kvm: x86: remove vmx_vm_has_apicv() outside of hwapic_isr_update() Tiejun Chen
2014-12-01 11:43 ` Paolo Bonzini
2014-12-19 2:32 ` Chen, Tiejun
2014-12-19 11:12 ` Paolo Bonzini
2014-12-22 9:01 ` Chen, Tiejun [this message]
2014-12-22 9:33 ` 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=5497DDD9.4000300@intel.com \
--to=tiejun.chen@intel.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.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.