Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <07348bb2-c8a5-41d0-afca-26c1056570a5.bangcai.hrg@alibaba-inc.com>
 <CANRm+CwZq=FbCwRcyO=C7YinLevmMuVVu9auwPqyho3o-4Y-wQ@mail.gmail.com> <660daad7-afb0-496d-9f40-a1162d5451e2.bangcai.hrg@alibaba-inc.com>
In-Reply-To: <660daad7-afb0-496d-9f40-a1162d5451e2.bangcai.hrg@alibaba-inc.com>
From:   Wanpeng Li <kernellwp@gmail.com>
Date:   Tue, 25 Feb 2020 16:41:02 +0800
Message-ID: <CANRm+Cw08uxwW8iUi96CJjmvfbtSd6ePXpAPPScByhoNLCrAWQ@mail.gmail.com>
Subject: Re: [RFC] Question about async TLB flush and KVM pv tlb improvements
To:     =?UTF-8?B?5L2V5a655YWJKOmCpumHhyk=?= <bangcai.hrg@alibaba-inc.com>
Cc:     namit <namit@vmware.com>, peterz <peterz@infradead.org>,
        pbonzini <pbonzini@redhat.com>,
        "dave.hansen" <dave.hansen@intel.com>, mingo <mingo@redhat.com>,
        tglx <tglx@linutronix.de>, x86 <x86@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "dave.hansen" <dave.hansen@linux.intel.com>, bp <bp@alien8.de>,
        luto <luto@kernel.org>, kvm <kvm@vger.kernel.org>,
        =?UTF-8?B?5p6X5rC45ZCsKOa1t+aeqyk=?= <yongting.lyt@alibaba-inc.com>,
        =?UTF-8?B?5ZC05ZCv57++KOWQr+e/vik=?= <qixuan.wqx@alibaba-inc.com>,
        herongguang <herongguang@linux.alibaba.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 25 Feb 2020 at 15:53, =E4=BD=95=E5=AE=B9=E5=85=89(=E9=82=A6=E9=87=
=87) <bangcai.hrg@alibaba-inc.com> wrote:
>
> > On Tue, 25 Feb 2020 at 12:12, =E4=BD=95=E5=AE=B9=E5=85=89(=E9=82=A6=E9=
=87=87) <bangcai.hrg@alibaba-inc.com> wrote:
> >>
> >> Hi there,
> >>
> >> I saw this async TLB flush patch at https://lore.kernel.org/patchwork/=
patch/1082481/ , and I am wondering after one year, do you think if this pa=
tch is practical or there are functional flaws?
> >> From my POV, Nadav's patch seems has no obvious flaw. But I am not fam=
iliar about the relationship between CPU's speculation exec and stale TLB, =
since it's usually transparent from programing. In which condition would ma=
chine check occurs? Is there some reference I can learn?
> >> BTW, I am trying to improve kvm pv tlb flush that if a vCPU is preempt=
ed, as initiating CPU is not sending IPI to and waiting for the preempted v=
CPU, when the preempted vCPU is resuming, I want the VMM to inject an inter=
rupt, perhaps NMI, to the vCPU and letting vCPU flush TLB instead of flush =
TLB for the vCPU, in case the vCPU is not in kernel mode or disabled interr=
upt, otherwise stick to VMM flush. Since VMM flush using INVVPID would flus=
h all TLB of all PCID thus has some negative performance impacting on the p=
reempted vCPU. So is there same problem as the async TLB flush patch?
>
> > PV TLB Shootdown is disabled in dedicated scenario, I believe there
> > are already heavy tlb misses in overcommit scenarios before this
> > feature, so flush all TLB associated with one specific VPID will not
> > worse that much.
>
> If vcpus running on one pcpu is limited to a few, from my test, there
> can still be some beneficial. Especially if we can move all the logic to

Unless the vCPU is preempted.

> VMM eliminating waiting of IPI, however correctness of functionally
> is a concern. This is also why I found Nadav's patch, do you have
> any advice on this?