From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7E54D711CB for ; Wed, 20 Nov 2024 17:25:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 529926B00A5; Wed, 20 Nov 2024 12:25:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FF886B00A6; Wed, 20 Nov 2024 12:25:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C6FF6B00A7; Wed, 20 Nov 2024 12:25:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1F81C6B00A5 for ; Wed, 20 Nov 2024 12:25:12 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9708940E73 for ; Wed, 20 Nov 2024 17:25:11 +0000 (UTC) X-FDA: 82807148676.02.4EF035E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id A1BDA1C0016 for ; Wed, 20 Nov 2024 17:24:04 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W6Ob2J10; spf=pass (imf20.hostedemail.com: domain of vschneid@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732123326; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NwQHeFP341Wloxfk/aGaEw2//tmnfhH7zawS7RRNPiQ=; b=oZgG1HDQrx01ca0ikbKYyEUoU1pj8djfqrCs4TrGk1WbDQnVL3Y0n55u0fjFH8sWMr4LAj Gmb6LDRv9BRqFCOib8/RejhQT4UpyFpMbZ9ac7HNjrST6rJywxkXRuNcL0S/ZwN69bfgdE +Axd03i6S5CBidKnxyqB1lvBhOzJvCs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W6Ob2J10; spf=pass (imf20.hostedemail.com: domain of vschneid@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732123326; a=rsa-sha256; cv=none; b=i30NcNpJZDGLF1VOH8k7nZtLS6K9fe1gtTFJoME04w2YNxn0ANUNuWeoF9KxtBOvvRf44M fzFYO0qkS6fSDOysl9kQtoFPMu1p/9hHVowSLD1Roi13OE92HGdA2G16XsUXeOsnWtBznF uZ+Mol8vPy6d6q7QHy29uVnIyaZ5+5U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732123508; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NwQHeFP341Wloxfk/aGaEw2//tmnfhH7zawS7RRNPiQ=; b=W6Ob2J10/2c7waKBVza5oRG20BopXwlTaXFTBu4JJeTYWA7hUybcoMmWxW2zhaktk6umoy ZKXmgkettWjsV1+TacWdP9PHfBuNjBzxRO+As2txGxzxdrvv3hKheGm+8U75XXHkVhsFrn 53wnXAIVOxDk6NxU1/CFRyISlKhSWnM= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-449-df20A23bN4ibCkOxq_j7yQ-1; Wed, 20 Nov 2024 12:25:07 -0500 X-MC-Unique: df20A23bN4ibCkOxq_j7yQ-1 X-Mimecast-MFC-AGG-ID: df20A23bN4ibCkOxq_j7yQ Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7b2f2db16cfso783674785a.3 for ; Wed, 20 Nov 2024 09:25:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732123507; x=1732728307; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NwQHeFP341Wloxfk/aGaEw2//tmnfhH7zawS7RRNPiQ=; b=q1drgyBPBJgKh7OmCzOcrqJIMw9ExaKw199TjdFrglcL32UBnu+OWX+1nw74KIJScy l9bgF7hBwRJQULd+tgEsvRyGFhoWc2fw3YA/xrrdJu+kBY5ClNGtV5vfGQ90pnEjrmEH BAFD8zWeEIV2E7DzxN5l1N/ktp2Umo/FgKdlUD7KkzNiHEJR9FxBBthqtDkszrqhhEXw 6rP0RamDaBkqnISAj4d8kjfUr8drcyXnGviqLjHFdbkPvfXhijVtEWPouG4C5jzR5Rul j+AcsP8bfSeaiWw/iAzDMZAJ63t6WFJK0LARizh2QSxrnanWe8W+g5gLTXD+o5BaEMIc 35+Q== X-Forwarded-Encrypted: i=1; AJvYcCXmBbrqjpUXZscem3vCeIpTjMA4lEjahq8DpwTOoZpc26V1xJn6WMfa3b7vF7DZfq0x+9JRfNxACQ==@kvack.org X-Gm-Message-State: AOJu0YzzbaQc4LcnqaEKzzs/BcdbltO8Zgh5A32y+j8qMole570OlnNZ FMEXevZij3Gno9IRy5Vf5OfzjhrNOCHKbkaNWGlfh2p4UCPU0n4xZrsCQP5LJKKw9p5x7EY1N3V 3se9DxOiYUkLDYl1c4evQpSh9yxEi0eKcsiRVfdF4IFnqle/e X-Received: by 2002:a05:620a:1917:b0:7b1:4077:4922 with SMTP id af79cd13be357-7b42eed7a6cmr466277085a.56.1732123506969; Wed, 20 Nov 2024 09:25:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IEJUDAeOvDitH46UyLYMmyy56kTy+imKK6wbeTl1oyZtnWZnUtyXKV7jcsxOZ4MHEPMTaXrqA== X-Received: by 2002:a05:620a:1917:b0:7b1:4077:4922 with SMTP id af79cd13be357-7b42eed7a6cmr466270685a.56.1732123506592; Wed, 20 Nov 2024 09:25:06 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b48523386esm117874785a.93.2024.11.20.09.24.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2024 09:25:05 -0800 (PST) From: Valentin Schneider To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, x86@kernel.org, rcu@vger.kernel.org, linux-kselftest@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Wanpeng Li , Vitaly Kuznetsov , Andy Lutomirski , Frederic Weisbecker , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Josh Poimboeuf , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Nadav Amit , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Juri Lelli , Marcelo Tosatti , Yair Podemsky , Daniel Wagner , Petr Tesarik Subject: Re: [RFC PATCH v3 13/15] context_tracking,x86: Add infrastructure to defer kernel TLBI In-Reply-To: <20241120153221.GM38972@noisy.programming.kicks-ass.net> References: <20241119153502.41361-1-vschneid@redhat.com> <20241119153502.41361-14-vschneid@redhat.com> <20241120152216.GM19989@noisy.programming.kicks-ass.net> <20241120153221.GM38972@noisy.programming.kicks-ass.net> Date: Wed, 20 Nov 2024 18:24:56 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: M-_cg_uM6BDtX-ob1hBh0CcjlXWOnFbyp2QQ5YndPtg_1732123507 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A1BDA1C0016 X-Stat-Signature: fq44hq9zxurkgr1rtb4y385mhqkyd38t X-Rspam-User: X-HE-Tag: 1732123444-744920 X-HE-Meta: U2FsdGVkX1+cFMO8pvwgq/D79fD/dE6XD3AmAQoeW7uVVkGi672XZK579L/PAbCmP5BGv1vVx1cSpc/Hhb22MWsn3sCzibsmF5Ngumr7Ez0wkaEKthnhO0TMv5B75vV14v5G0Sl745PcXym5IGQ9NpJeaoGL0+p7pi5IbKJ0BI2vkwYdQH3KzyywSoIOKhrt6bbYqB5ke/ysztocS/xBuQfllXfy+s8AIVYDYhlucVUfN3zztfYPxmuS79gyLHwYu0cuWo5js/PfJFY7zE7+uzB+kWb/8s0NuZNlr91A5Zi3lcOSizgulF1JW/RmtD0iZqIXv7hzBj6owEeHC0+JZnv0JIjOMCpV6pWAhwev6QcPIAV+Av5fmGNFaK1juD7ZziT/MYPTL2QjliB35m1TqnWUjfg7tEAh28pCCVUeTIgqHwFEB+dAP6VqIR7LEkvRr7ymkAnVnTR+DnMWMkRV28Y5kV1JOJkGKSxPXTVuO9XENFiWAsNn5FpBY8zvh+dD6UJzZuaxd20p6HqUNeO8rKyhY5Uqj26bYcXfd/dNPZ/FG34zl9lQ5GO7okqNL0uRZ0bLKwwZvEfT/hDYs33AR1/PtSMFZDC2UCbA4pHo3kqyQkkhtGd6OTVVt/C/w8b27of08la9T+jM5FuCCM8ApeKc085B4zgpBGQHOG9txfy7QVR+6z9izAVMa/LBVfUY3YoCKYmBY7P2tKVthWMvOvan2HxKxZp+0fBi0Aks3TLn75CgOYlac0KSrZCp82U53E5vebMcJiwSeEG9ZspaXvM9x/uf4wXLLsF9cubImDFtCnCA/PwkvswbwbZ/DCQH4XGIW0d1ZIXs+4TgwHz7gjlrq5kZhswZEggsjmA/xTiAZy791+Xto16lsLPjr7kbv585prKc1zb56Sy5xO35AWhylKa05npKSvPqSUvhjRL51FQILrPpVTGGVWD9+l1+dum4U02/ovU/7Nhfw+4 f+FUEzR5 nX96IeP4RHd2Kq4KYQbfhnG/muvbzQRXQXQ3X6rRgusA4FI2E7QFtCxspq4jf2BD7iSu1Y/DmqTQmwx4o2Z99K2UK/LiaG3hs140lsEa2WcZxGsF8YFr/OdJ0lJKHVTtQXoFHSL8Bv5FpJ1A3bEkNkbzp+DUFYvHoFuJ16Uz3R0GQvB4IrXsBkdHYWVZsePVgyQ1rgsN8TZ8FLKoxkm8f56yo5JP9T7urHpVsl5UogrfIurW6O3kwuj2e9R5zrQjZl6Vp6d5ugzupzZgI7pUeWNa98Xkz0qL5OPLvXEREup4i6Tk679dWm4bKSVCn/5GSFc6ziaeqUCBieTVsFTgpiVgo24rIyylsbEUk/gcdOtKLm6pylZF9LcJMk+/iuagWRA+5yFpVcYkkGJoGm3poFlR4HnQXNf8/5Ji0OCv+9gxMSI0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 20/11/24 16:32, Peter Zijlstra wrote: > On Wed, Nov 20, 2024 at 04:22:16PM +0100, Peter Zijlstra wrote: >> On Tue, Nov 19, 2024 at 04:35:00PM +0100, Valentin Schneider wrote: >> >> > +void noinstr __flush_tlb_all_noinstr(void) >> > +{ >> > + /* >> > + * This is for invocation in early entry code that cannot be >> > + * instrumented. A RMW to CR4 works for most cases, but relies on >> > + * being able to flip either of the PGE or PCIDE bits. Flipping CR4.PCID >> > + * would require also resetting CR3.PCID, so just try with CR4.PGE, else >> > + * do the CR3 write. >> > + * >> > + * XXX: this gives paravirt the finger. >> > + */ >> > + if (cpu_feature_enabled(X86_FEATURE_PGE)) >> > + __native_tlb_flush_global_noinstr(this_cpu_read(cpu_tlbstate.cr4)); >> > + else >> > + native_flush_tlb_local_noinstr(); >> > +} >> >> Urgh, so that's a lot of ugleh, and cr4 has that pinning stuff and gah. >> >> Why not always just do the CR3 write and call it a day? That should also >> work for paravirt, no? Just make the whole write_cr3 thing noinstr and >> voila. > > Oh gawd, just having looked at xen_write_cr3() this might not be > entirely trivial to mark noinstr :/ ... I hadn't even seen that. AIUI the CR3 RMW is not "enough" if we have PGE enabled, because then global pages aren't flushed. The question becomes: what is held in global pages and do we care about that when it comes to vmalloc()? I'm starting to think no, but this is x86, I don't know what surprises are waiting for me. I see e.g. ds_clear_cea() clears PTEs that can have the _PAGE_GLOBAL flag, and it correctly uses the non-deferrable flush_tlb_kernel_range().