Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59C48C433F5 for ; Tue, 30 Nov 2021 16:02:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243320AbhK3QFW (ORCPT ); Tue, 30 Nov 2021 11:05:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243070AbhK3QFP (ORCPT ); Tue, 30 Nov 2021 11:05:15 -0500 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83FF5C061574 for ; Tue, 30 Nov 2021 08:01:55 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id x131so21051813pfc.12 for ; Tue, 30 Nov 2021 08:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=u7qkJO95z6PA+5n1Ta+ydAPJV1GYiaGJee3oSFozDEQ=; b=IFt8Tn+vxT21IpZwc1G2oIIymlaJa/rS9tPtD65lbJffdgHBV1ma5O+UrZYwQ+fpdE uwo6I7onE1BcdE7rFH+Hyh0hfFqAisvMusQkVDnpcHVSrvYxwu/WDFInlFXrsly+Ij2o 2/e4EmCPBpf191/pzWGolf7xwlV4RVdA29Ob/MYDXJBNJmWraO+ef5IZrdWd5kTDzB4e d43mrcg7DtKvEkstc8pI3DgJG4GKmHwqmVLDDfyMhJ97ZgjBvOWiiQyopaZ3i2tEV+Wm Ley8rcpzQAb/T5TWz2UVrLchpAFSSyi8rw3PYzcbp2+rhJJ9SoKb3AYBUyt5a90Advl4 9BwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=u7qkJO95z6PA+5n1Ta+ydAPJV1GYiaGJee3oSFozDEQ=; b=AjpdSOWcPlpp19k4cuy0nhXGVxsKTlndG3eOffBTLeKdKCmNs/ZNec7WNGLWBEUHjZ WswqHDWaeybumg4P2+gT4XS6o5gfNCEImmz6xYOQaRh3QVoD5P871XjZUV3lnwm4Hm+f j5KgkqtrFweRF0MJNHBt1BOD5/CgnjX8OOclUSv/n7jcGqWkAPBXxd1pYt3SCnRQ36Gg kdfj32G/PDFRMNta0c9pmk9UZ34gcW8U7oEwakJwxR+p0pMMFShZf+7e7RcxAxKUViB0 34nvu3FGswtpJ9ai7u9+giGaoqZc3oDUoC2o3d0S/HY7I9fPJlFEXEcsGH0l5IO/b87j GZeg== X-Gm-Message-State: AOAM532nHlfteYo5LoFbK1aifI/FoqV2j5pmfUmIx0Q4/Ofn+d4gnpxE Kc6MIFpIVS8DPX81bNQdW9hCag== X-Google-Smtp-Source: ABdhPJzONHfSHYXg+nJ0762Y3NxbBOp1zkuKvTXs/1E3XWI7EUSQt6W9dr/3AVTdAHDoxFeRyZbz9A== X-Received: by 2002:a65:4bc6:: with SMTP id p6mr23381pgr.544.1638288114791; Tue, 30 Nov 2021 08:01:54 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id lp12sm3366048pjb.24.2021.11.30.08.01.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 08:01:54 -0800 (PST) Date: Tue, 30 Nov 2021 16:01:50 +0000 From: Sean Christopherson To: Peter Xu Cc: Ben Gardon , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Peter Shier , David Matlack , Mingwei Zhang , Yulei Zhang , Wanpeng Li , Xiao Guangrong , Kai Huang , Keqian Zhu , David Hildenbrand Subject: Re: [PATCH 15/15] KVM: x86/mmu: Promote pages in-place when disabling dirty logging Message-ID: References: <20211115234603.2908381-1-bgardon@google.com> <20211115234603.2908381-16-bgardon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 30, 2021, Peter Xu wrote: > On Mon, Nov 29, 2021 at 10:31:14AM -0800, Ben Gardon wrote: > > 2. There could be a pointer to the page table in a vCPU's paging > > structure caches, which are similar to the TLB but cache partial > > translations. These are also cleared out on TLB flush. > > Could you elaborate what's the structure cache that you mentioned? I thought > the processor page walker will just use the data cache (L1-L3) as pgtable > caches, in which case IIUC the invalidation happens when we do WRITE_ONCE() > that'll invalidate all the rest data cache besides the writter core. But I > could be completely missing something.. Ben is referring to the Intel SDM's use of the term "paging-structure caches" Intel CPUs, and I'm guessing other x86 CPUs, cache upper level entries, e.g. the L4 PTE for a given address, to avoid having to do data cache lookups, reserved bits checked, A/D assists, etc... Like full VA=>PA TLB entries, these entries are associated with the PCID, VPID, EPT4A, etc... The data caches are still used when reading PTEs that aren't cached in the TLB, the extra caching in the "TLB" is optimization on top. 28.3.1 Information That May Be Cached Section 4.10, “Caching Translation Information” in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A identifies two kinds of translation-related information that may be cached by a logical processor: translations, which are mappings from linear page numbers to physical page frames, and paging-structure caches, which map the upper bits of a linear page number to information from the paging-structure entries used to translate linear addresses matching those upper bits.