linux-kernel - Re: [PATCH] KVM: lapic: sync highest ISR to hardware apic on EOI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53833C97.3040305@redhat.com>
Date:	Mon, 26 May 2014 15:07:35 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	"Zhang, Yang Z" <yang.z.zhang@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"mtosatti@...hat.com" <mtosatti@...hat.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] KVM: lapic: sync highest ISR to hardware apic on EOI

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/