[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <828b24bb-a55b-dd5f-a514-ef3e182db5cd@amd.com>
Date: Wed, 13 Mar 2019 19:03:31 +0000
From: "Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>
To: Oren Twaig <oren@...lemp.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Shai (Shai@...leMP.com)" <Shai@...lemp.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"rkrcmar@...hat.com" <rkrcmar@...hat.com>,
"Grimm, Jon" <Jon.Grimm@....com>
Subject: Re: [PATCH] svm: Fix AVIC incomplete IPI emulation
Oren
On 3/13/19 8:05 PM, Oren Twaig wrote:
> Hi Suravee,
>
> Turns out, the _same_ bug was already discussed in the past by
> yourself, Paolo and Radim (both now 'cc'-ed)
>
> Please read it here:
> https://patchwork.kernel.org/patch/8292231/
>
>
> After reading that thread, I have couple of questions:
>
> First,
>
> You wrote : "I have tried NOT setting the IRR, and only
> kick_vcpu(). And things seem to work fine. Therefore, I think your
> analysis is likely to be correct."
>
> AFAIU, it means that the below patch is wrong just as Paolo
> suggested in his original answer and you did fixed it back than, but the
> code is now back ?
Thanks for the recap. I was chasing a bug and totally forgot about this
discussion. I just found the reason why irr_pending was not set to 1 in my test,
which then causes the target vcpu to never get wake up and scheduled to process
the IRR bit that was set by AVIC as part of sending IPI.
I will send out a patch to revert and clean up this mess. Thanks for catching this.
And sorry for confusion.
Thanks,
Suravee
Powered by blists - more mailing lists