Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1250012imc; Mon, 11 Mar 2019 09:32:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqz3XDj6GAvFv94V2usuWzjEpyInlUDvhBh6ZBeKaspQ3N+rR0P7u2jH1IantnibZzDXJaq7 X-Received: by 2002:a63:29c4:: with SMTP id p187mr9680303pgp.230.1552321938515; Mon, 11 Mar 2019 09:32:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552321938; cv=none; d=google.com; s=arc-20160816; b=Ivpq8VWh9yHlKqsujI279OH3x9CEesc1d4Sxo1Rm09JnQIQ6UgO71KdS4gOguaVtQz BnnI/l+MR7rpafJxpuVePrG/w2Yi0QIO6m5m5K8/XwLVawoQ5V4agmiUn/d113UAoYnO n6Nha8uMcfKgMvrl3c4CgF8ZCMCQXoTknSoWm8s8PDprXShgnmnWfQMu4dSfY8/DA34V GKflDljwpqDOLJVNQ5enH+fWHhZxZHi/MNMgK6FqdCrqc9bRh9o7kxZKs3uXE4+muSl6 7uaHcAWojmIrU4HJFDwqtYO1WqcDjIh+6RNHmAbgcNDmz/qGigP+XiZo6umiGsem0r65 UBpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:subject :from:cc:to; bh=U7lPWpYNdbyLABM51CMHPBMmPmTYv/xwnGIfCcQFjVk=; b=jW+ScfYALK5JsYzigkB+V+WrCk5x0n9jUXPrSVL7KL+P44S/CAWMfm1K/lCdOefAVx od+EDIqEZalXJ7au32GwruERySvT0ZNeqMZ+50jFtHUQAVqVTQaTp+nB8GNW0z9iUqeJ hPYhlFY1Z5frQCOBdi/p4Zu9Hx6s3LbFL20XEWCTzZekPXw4x6Ne5qeOvsOSPf+D7Ke4 1yy4f/tFqDvgcsvH4r+YDJjc+Aobh/DFbHew78H9z0hmTA8O7TJ9+RtN9+DkyXj71d0i /PVE9GZXuGALq1TY7u0tM86kwatl2DmLAZA3VlQSVvxndbE1w62vYKjyZCQSIxs1ZBJ4 nuVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w8si5018159pgp.320.2019.03.11.09.32.02; Mon, 11 Mar 2019 09:32:18 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727667AbfCKQbi (ORCPT + 99 others); Mon, 11 Mar 2019 12:31:38 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:34232 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726675AbfCKQbi (ORCPT ); Mon, 11 Mar 2019 12:31:38 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 405269064B4B43CFC3F3; Tue, 12 Mar 2019 00:31:36 +0800 (CST) Received: from [127.0.0.1] (10.177.29.32) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.408.0; Tue, 12 Mar 2019 00:31:29 +0800 To: , , , , , CC: , , , Wang Haibin , "yuzenghui@huawei.com" , , From: Zheng Xiang Subject: [RFC] Question about TLB flush while set Stage-2 huge pages Message-ID: <5f712cc6-0874-adbe-add6-46f5de24f36f@huawei.com> Date: Tue, 12 Mar 2019 00:31:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.32] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, While a page is merged into a transparent huge page, KVM will invalidate Stage-2 for the base address of the huge page and the whole of Stage-1. However, this just only invalidates the first page within the huge page and the other pages are not invalidated, see bellow: +---------------+--------------+ |abcde 2MB-Page | +---------------+--------------+ TLB before setting new pmd: +---------------+--------------+ | VA | PAGESIZE | +---------------+--------------+ | a | 4KB | +---------------+--------------+ | b | 4KB | +---------------+--------------+ | c | 4KB | +---------------+--------------+ | d | 4KB | +---------------+--------------+ TLB after setting new pmd: +---------------+--------------+ | VA | PAGESIZE | +---------------+--------------+ | a | 2MB | +---------------+--------------+ | b | 4KB | +---------------+--------------+ | c | 4KB | +---------------+--------------+ | d | 4KB | +---------------+--------------+ When VM access *b* address, it will hit the TLB and result in TLB conflict aborts or other potential exceptions. For example, we need to keep tracking of the VM memory dirty pages when VM is in live migration. KVM will set the memslot READONLY and split the huge pages. After live migration is canceled and abort, the pages will be merged into THP. The later access to these pages which are READONLY will cause level-3 Permission Fault until they are invalidated. So should we invalidate the tlb entries for all relative pages(e.g a,b,c,d), like __flush_tlb_range()? Or we can call __kvm_tlb_flush_vmid() to invalidate all tlb entries. -- Thanks, Xiang