On Fri, 2021-12-10 at 13:07 +0100, Paolo Bonzini wrote: > On 12/9/21 12:54, Maxim Levitsky wrote: > > It is possible that during the AVIC incomplete IPI vmexit, > > its handler will set irr_pending to true, > > but the target vCPU will still see the IRR bit not set, > > due to the apparent lack of memory ordering between CPU's vIRR write > > that is supposed to happen prior to the AVIC incomplete IPI > > vmexit and the write of the irr_pending in that handler. > > Are you sure about this? Store-to-store ordering should be > guaranteed---if not by the architecture---by existing memory barriers > between vmrun returning and avic_incomplete_ipi_interception(). For > example, srcu_read_lock implies an smp_mb(). > > Even more damning: no matter what internal black magic the processor > could be using to write to IRR, the processor needs to order the writes > against reads of IsRunning on processors without the erratum. That > would be equivalent to flushing the store buffer, and it would imply > that the write of vIRR is ordered before the write to irr_pending. > > Paolo > Yes I almost 100% sure now that this patch is wrong. the code was just seeing irr_pending true because it is set to true while APICv/AVIC is use, and was not seeing yet the vIRR bits, because they didn't arrive yet. This this patch isn't needed. Thanks again for help! I am testing your version of fixes to avic inhibition races, and then I'll send a new version of these patches. Best regards, Maxim Levitsky
