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>
In-Reply-To: <07348bb2-c8a5-41d0-afca-26c1056570a5.bangcai.hrg@alibaba-inc.com>
From:   Wanpeng Li <kernellwp@gmail.com>
Date:   Tue, 25 Feb 2020 14:31:20 +0800
Message-ID: <CANRm+CwZq=FbCwRcyO=C7YinLevmMuVVu9auwPqyho3o-4Y-wQ@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>,
        "yongting.lyt" <yongting.lyt@alibaba-inc.com>,
        =?UTF-8?B?5ZC05ZCv57++KOWQr+e/vik=?= <qixuan.wqx@alibaba-inc.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 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/pat=
ch/1082481/ , and I am wondering after one year, do you think if this patch=
 is practical or there are functional flaws?
> From my POV, Nadav's patch seems has no obvious flaw. But I am not famili=
ar about the relationship between CPU's speculation exec and stale TLB, sin=
ce it's usually transparent from programing. In which condition would machi=
ne check occurs? Is there some reference I can learn?
> BTW, I am trying to improve kvm pv tlb flush that if a vCPU is preempted,=
 as initiating CPU is not sending IPI to and waiting for the preempted vCPU=
, when the preempted vCPU is resuming, I want the VMM to inject an interrup=
t, 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 interrupt=
, otherwise stick to VMM flush. Since VMM flush using INVVPID would flush a=
ll TLB of all PCID thus has some negative performance impacting on the pree=
mpted 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.

    Wanpeng