From: Paolo Bonzini <pbonzini@redhat.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "mtosatti@redhat.com" <mtosatti@redhat.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] KVM: lapic: sync highest ISR to hardware apic on EOI
Date: Mon, 26 May 2014 15:07:35 +0200 [thread overview]
Message-ID: <53833C97.3040305@redhat.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0AAD347A@SHSMSX104.ccr.corp.intel.com>
Il 26/05/2014 05:44, Zhang, Yang Z ha scritto:
> Paolo Bonzini wrote on 2014-05-23:
>> When Hyper-V enlightenments are in effect, Windows prefers to issue an
>> Hyper-V MSR write to issue an EOI rather than an x2apic MSR write.
>> The Hyper-V MSR write is not handled by the processor, and besides
>> being slower, this also causes bugs with APIC virtualization. The
>> reason is that on EOI the processor will modify the highest in-service
>> interrupt (SVI) field of the VMCS, as explained in section 29.1.4 of
>> the SDM.
>>
>
> Not only SVI update. It also includes ISR and PPR update. During PPR
> update, a new pending interrupt may be recognized and inject to guest.
Right, but SVI update is the only part that is missing. Writing VISR is
done by apic_clear_isr and PPR virtualization is done by
apic_update_ppr. PPR virtualization is also done anyway at any VM entry,
together with evaluating and delivering pending virtual interrupts.
We'll do two PPR virtualizations (one in KVM, one in the processor), but
that's ok because they're idempotent.
We also operate as if the EOI exit bitmap was all ones, but that's ok
because a useless kvm_ioapic_send_eoi is not harmful.
>> static inline void apic_clear_isr(int vec, struct kvm_lapic *apic)
>> {
>> - if (__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
>> + struct kvm_vcpu *vcpu;
>> + if (!__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
>> + return;
>> +
>> + vcpu = apic->vcpu;
>> +
>> + /*
>> + * We do get here for APIC virtualization enabled if the guest
>> + * uses the Hyper-V APIC enlightenment. In this case we may need
>> + * to trigger a new interrupt delivery by writing the SVI field;
>> + * 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)))
>> + kvm_x86_ops->hwapic_isr_update(vcpu->kvm,
>> + apic_find_highest_isr(apic));
>
> If there is a pending interrupt, will it be recognized? I am not
> looking into the Hyper-V enlightenments code, not sure whether it
> already covers interrupt recognition. But if it doesn't do it, then we
> need to do it.
Yes, on the next VM entry the processor will do RVI to the PPR. Before
the VM entry KVM_REQ_EVENT will also be processed, which updates RVI in
hwapic_irr_update
.
Paolo
next prev parent reply other threads:[~2014-05-26 13:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 14:51 [PATCH] KVM: lapic: sync highest ISR to hardware apic on EOI Paolo Bonzini
2014-05-26 3:44 ` Zhang, Yang Z
2014-05-26 13:07 ` Paolo Bonzini [this message]
2014-05-27 0:26 ` Zhang, Yang Z
2014-05-26 14:28 ` Michael S. Tsirkin
2014-05-26 14:56 ` Paolo Bonzini
2014-05-26 15:39 ` Michael S. Tsirkin
2014-05-28 16:57 ` Marcelo Tosatti
2014-05-28 17:11 ` 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=53833C97.3040305@redhat.com \
--to=pbonzini@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yang.z.zhang@intel.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;
as well as URLs for NNTP newsgroup(s).