linux-kernel - 回复：[RFC] Question about async TLB flush and KVM pv tlb improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <600a0d33-b995-453e-b678-0436908cd857.bangcai.hrg@alibaba-inc.com>
Date:   Tue, 25 Feb 2020 15:25:30 +0800
From:   "何容光(邦采)" <bangcai.hrg@...baba-inc.com>
To:     "Nadav Amit" <namit@...are.com>
Cc:     "peterz" <peterz@...radead.org>, "kernellwp" <kernellwp@...il.com>,
        "pbonzini" <pbonzini@...hat.com>,
        "dave.hansen" <dave.hansen@...el.com>, "mingo" <mingo@...hat.com>,
        "tglx" <tglx@...utronix.de>, "x86" <x86@...nel.org>,
        "linux-kernel" <linux-kernel@...r.kernel.org>,
        "dave.hansen" <dave.hansen@...ux.intel.com>, "bp" <bp@...en8.de>,
        "luto" <luto@...nel.org>, "kvm" <kvm@...r.kernel.org>,
        "林永听(海枫)" <yongting.lyt@...baba-inc.com>,
        "吴启翾(启翾)" <qixuan.wqx@...baba-inc.com>,
        "herongguang" <herongguang@...ux.alibaba.com>
Subject: 回复：[RFC] Question about async TLB flush and KVM pv tlb improvements

>> On Feb 24, 2020, at 8:12 PM, 何容光(邦采) <bangcai.hrg@...baba-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 patch is practical or there are
>> functional flaws? From my POV, Nadav's patch seems has no obvious flaw.
>> But I am not familiar about the relationship between CPU's speculation
>> exec and stale TLB, since it's usually transparent from programing. In
>> which condition would machine check occurs? Is there some reference I can
>> learn?

> I was/am held back by personal issues that consume my free time, which
> prevented me from sending a new version so far.

Good to hear that :)

> As for the patch-set - the greatest benefit in performance comes from
> running local/remote TLB flushes concurrently, and I will respin another
> version of that in two weeks time. I will send the async flushes afterwards.

In non-overcommitment virtualization environment, I think this will be 
beneficial. Since the async implementation still need remote CPU’s IPI 
response, pv tlb flush can address this scenario’s need.

Do you have any reference about relationship between CPU's speculation
and stale TLB, especially causing machine check? I want to learn about this, 
thanks.