From nobody Mon Feb 9 02:28:22 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail(p=none dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1584729898; cv=none; d=zohomail.com; s=zohoarc; b=WfjLuClbCOqrZ1vvzFquoQNoxW2p5CNI36Czi4+bAN8X6UZCbjvQNUizqb8iqhLpN+2JhXJLm1nBpJ/qmzUpF9EgRttGUzcO+GvgTnKyBPCvvLAHrDuJKLs5MUGWwQKaQY8WmgDs6TzBbxRXz4Rt4qV2ZFCHj+wZvlaenyRsH1A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1584729898; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=x6z/CYCPgQP+J1dzh20e9JzrajUMrIexZUiiSJ6FP4o=; b=ZRhGujgkjXFNpqhHlCn9EWa7Qr2OXxCR8aZYRWWHxmL5aYA2SR6CIseu2DQzLbNX0ROPY7LbsAvdOqEr5A1e1u7QB2Pxz7dT5FEQdCoi9hnuqwh/Ds9jtbIU/y/MxS1VidGqf9+ZMMD+R8tEY7EmV1lppSkkBwoihKdidkXVZdM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1584729898452340.0793318198031; Fri, 20 Mar 2020 11:44:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jFMc2-0006ix-3u; Fri, 20 Mar 2020 18:43:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jFMc1-0006im-CY for xen-devel@lists.xenproject.org; Fri, 20 Mar 2020 18:43:17 +0000 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a6f78852-6ada-11ea-bde2-12813bfff9fa; Fri, 20 Mar 2020 18:43:13 +0000 (UTC) X-Inumbo-ID: a6f78852-6ada-11ea-bde2-12813bfff9fa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1584729793; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/deMyZ1X51RFAWtQH00mG2VTaZBC1SapOIz0tDOVyz0=; b=BR4yH45tSqwOhYWvYXU/Q8X+4vIRnvnJ8l57fYBvuvpk/gRhZyZo3UzG MtRQPWA48d73NLCebzBcn+Df6PkxIkQ6ph85Jpe1A6DAwZHLI0ouMWfOM Bm9o9plGlCq2y/YoX3nlNnwDlRNsq5S+ZXl6VOJ3wV63Pk8Kv/kYfPTRI U=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: h/EfITXZa2jAe4Rq2hiG1D6x5jzVEK87AdwwEuNpa9/UoTEuIyHV3Sx8cG97MtFj/JSqVEmAMu 0Rp79FILVkBJPo5lBFGxJ7aYwC79nw75wkhDHOptj0Ek+4MrZSUJ0vGCJlPLedNnu+gZiL75Xl 3kGd8Ko3R8eV6AJqi4Ks3Ihob5EOQ6iIkdVvOG2qePZFvFjhu9+WozWxxcRKeeJQHa/n3ZPUhh EeDQTzZi8ZwkD0ARyYiNR7vuSt6+7/i9pdpjWtoh6jMGxgYDkgvRR8EWt2kvVuPeNoWpmw0mNN G7g= X-SBRS: 2.7 X-MesageID: 14372883 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.72,285,1580792400"; d="scan'208";a="14372883" From: Roger Pau Monne To: Date: Fri, 20 Mar 2020 19:42:39 +0100 Message-ID: <20200320184240.41769-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200320184240.41769-1-roger.pau@citrix.com> References: <20200320184240.41769-1-roger.pau@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v8 2/3] x86/tlb: allow disabling the TLB clock X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , Jan Beulich , Roger Pau Monne Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) The TLB clock is helpful when running Xen on bare metal because when doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the last flush. This is not the case however when Xen is running virtualized, and the underlying hypervisor provides mechanism to assist in performing TLB flushes: Xen itself for example offers a HVMOP_flush_tlbs hypercall in order to perform a TLB flush without having to IPI each CPU. When using such mechanisms it's no longer possible to keep a timestamp of the flushes on each CPU, as they are performed by the underlying hypervisor. Offer a boolean in order to signal Xen that the timestamped TLB shouldn't be used. This avoids keeping the timestamps of the flushes, and also forces NEED_FLUSH to always return true. No functional change intended, as this change doesn't introduce any user that disables the timestamped TLB. Signed-off-by: Roger Pau Monn=C3=A9 Reviewed-by: Wei Liu Acked-by: Jan Beulich --- xen/arch/x86/flushtlb.c | 19 +++++++++++++------ xen/include/asm-x86/flushtlb.h | 17 ++++++++++++++++- 2 files changed, 29 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c index c81e53c0ae..22b2e84329 100644 --- a/xen/arch/x86/flushtlb.c +++ b/xen/arch/x86/flushtlb.c @@ -32,6 +32,9 @@ u32 tlbflush_clock =3D 1U; DEFINE_PER_CPU(u32, tlbflush_time); =20 +/* Signals whether the TLB flush clock is in use. */ +bool __read_mostly tlb_clk_enabled =3D true; + /* * pre_flush(): Increment the virtual TLB-flush clock. Returns new clock v= alue. *=20 @@ -82,12 +85,13 @@ static void post_flush(u32 t) static void do_tlb_flush(void) { unsigned long flags, cr4; - u32 t; + u32 t =3D 0; =20 /* This non-reentrant function is sometimes called in interrupt contex= t. */ local_irq_save(flags); =20 - t =3D pre_flush(); + if ( tlb_clk_enabled ) + t =3D pre_flush(); =20 if ( use_invpcid ) invpcid_flush_all(); @@ -99,7 +103,8 @@ static void do_tlb_flush(void) else write_cr3(read_cr3()); =20 - post_flush(t); + if ( tlb_clk_enabled ) + post_flush(t); =20 local_irq_restore(flags); } @@ -107,7 +112,7 @@ static void do_tlb_flush(void) void switch_cr3_cr4(unsigned long cr3, unsigned long cr4) { unsigned long flags, old_cr4; - u32 t; + u32 t =3D 0; =20 /* Throughout this function we make this assumption: */ ASSERT(!(cr4 & X86_CR4_PCIDE) || !(cr4 & X86_CR4_PGE)); @@ -115,7 +120,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr= 4) /* This non-reentrant function is sometimes called in interrupt contex= t. */ local_irq_save(flags); =20 - t =3D pre_flush(); + if ( tlb_clk_enabled ) + t =3D pre_flush(); hvm_flush_guest_tlbs(); =20 old_cr4 =3D read_cr4(); @@ -168,7 +174,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr= 4) if ( cr4 & X86_CR4_PCIDE ) invpcid_flush_all_nonglobals(); =20 - post_flush(t); + if ( tlb_clk_enabled ) + post_flush(t); =20 local_irq_restore(flags); } diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h index 579dc56803..724455ae0c 100644 --- a/xen/include/asm-x86/flushtlb.h +++ b/xen/include/asm-x86/flushtlb.h @@ -21,10 +21,21 @@ extern u32 tlbflush_clock; /* Time at which each CPU's TLB was last flushed. */ DECLARE_PER_CPU(u32, tlbflush_time); =20 -#define tlbflush_current_time() tlbflush_clock +/* TLB clock is in use. */ +extern bool tlb_clk_enabled; + +static inline uint32_t tlbflush_current_time(void) +{ + /* Returning 0 from tlbflush_current_time will always force a flush. */ + return tlb_clk_enabled ? tlbflush_clock : 0; +} =20 static inline void page_set_tlbflush_timestamp(struct page_info *page) { + /* Avoid the write if the TLB clock is disabled. */ + if ( !tlb_clk_enabled ) + return; + /* * Prevent storing a stale time stamp, which could happen if an update * to tlbflush_clock plus a subsequent flush IPI happen between the @@ -67,6 +78,10 @@ static inline void tlbflush_filter(cpumask_t *mask, uint= 32_t page_timestamp) { unsigned int cpu; =20 + /* Short-circuit: there's no need to iterate if the clock is disabled.= */ + if ( !tlb_clk_enabled ) + return; + for_each_cpu ( cpu, mask ) if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) ) __cpumask_clear_cpu(cpu, mask); --=20 2.25.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel