[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160215192243.GA22531@potion.brq.redhat.com>
Date: Mon, 15 Feb 2016 20:22:44 +0100
From: Radim Krčmář <rkrcmar@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
joro@...tes.org, alex.williamson@...hat.com, gleb@...nel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org, wei@...hat.com,
sherry.hurwitz@....com
Subject: Re: [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC
2016-02-12 16:38+0100, Paolo Bonzini:
> On 12/02/2016 14:59, Suravee Suthikulpanit wrote:
>> + case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
>> + kvm_lapic_reg_write(apic, APIC_ICR2, icrh);
>> + kvm_lapic_reg_write(apic, APIC_ICR, icrl);
>
> Wouldn't this cause a double injection of the IPI if the following happens:
I think it will. (IRR was written to APIC pages, so hypervisor's only
job is to make sure that all targeted VCPUs eventually run.)
> The handling of races for IsRunning and incomplete IPIs has always been
> very confusing to me whenever I read the AVIC specification. It would
> be great if you could clarify this.
Yeah, we bug there as well: If all target VCPUs have IsRunning set and
are in the process of being scheduled out (avic_set_running false), then
there is no VMEXIT on IPI and the doorbell does nothing[1]; KVM desn't
re-check pending interrupts before actually scheduling out, therefore
VCPUs will wake only if another interrupt comes.
The hypervisor can manage the IsRunning as it wishes to, so KVM probably
should set IsRunning to false before scanning IRR.
---
1: I didn't find a single mention of a situation when doorbell arrives
outside of guest mode, so I presume that nothing happens.
Is it right?
Thanks.
Powered by blists - more mailing lists