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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5A87DCCFA03 for ; Mon, 3 Nov 2025 21:15:31 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4d0krd6ZbHz2yFs; Tue, 4 Nov 2025 08:15:29 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip="2600:3c0a:e001:78e:0:1991:8:25" ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1762186532; cv=none; b=WGKoy9mnQBoppRwEBY8FgqQU7PFwAqsQvhetVevQ8I0ECDQ/MyU6tj6oXiDyRsKJ056axzVAailG7W0AZeQuqqrTTq9S6ZTT449/6aDRFkLaoKxo8JhKF4xPiru0EMDtIvZNN4RR8oZ/T90ZLnU6L3eoLPJ8th8NX6o6u3pmrWygZvjVKsCXCSw+SyZ2lEh8re88JZtpTRRazqVk1T22ea/L5oKFdmT42npfYfqAw4jYviQ69Xe1sr/YaLapJPi30EruhkNBSe6qcFsC8svZDzim1FEwtxBIRdSWJ0F/1VCD920s0Y3oRbH6vJzMS4BALJjcz35Wz+GRrINkooaV3A== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1762186532; c=relaxed/relaxed; bh=nwOqk6r952fnoq6kqx5JJLxmDxQO3I/qHQLZzHd75RQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Mckqz/dfx0JgNXKKsETjcjZxF+AQcPcY4ReAJkg06SG/fQwEZRtU0V43vvIohYcXLR3HZhSxqaFj3iEOEWvuWaAE0nND3Hu2mp9vRy0Ks7aJ5M/x+wMslH45XdgOZk34Tx+gpYbJ19WJTROKixxWV8Kt8WJEwP+w3+OyEL8mdNNtm+HcQkXHtTRFKMxh4GimdEmAVAPviG4HkUm+9hGOwrmVWS+VYffptfg38oGf4b0bDYPlB1pQcKkC2f+WKEEFJ5TwWicHcBsp3E/fCZuB38g2vNzYDbKeVYmncRqGsPyvWASgowAw1fcaqATmBraNZxSIKpudKKm9mi6pOo1YIw== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=pMmG9L/w; dkim-atps=neutral; spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=david@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=pMmG9L/w; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=david@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [IPv6:2600:3c0a:e001:78e:0:1991:8:25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4d0cBW4NGWz30RJ for ; Tue, 4 Nov 2025 03:15:31 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 3D68643BB2; Mon, 3 Nov 2025 16:15:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22BE5C4CEE7; Mon, 3 Nov 2025 16:15:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762186529; bh=S0YKJr0SoBmysmz8IMr3QugNjlhYpJzfR41WjPWBUB4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=pMmG9L/wSj8xOcK/DzcO7x+pUKpbN+kaGWRhPKGT/hFa2p/Ay8Nl1Mzz1ZWUyScDa vucJ0XbF6T0spIoI3AD/0qxqWiVKMh+Mmks24qxQFDpKZf3Zexx64cDs61lCh6Efy6 od0TqupiK1VEnDg7glIHKRlBc357kZIMtV/jM6SD3qxje1H7u2r4taFzH3oyOWmxWM hHnL2j3jQ8KEJexQD4wpbJBjPfYdQst+gwFFqah20VMhXD96dyPMbnm/scOYZnijeO WcP/Ww9iS8dXs6EdOUxwooqxO/I0VbjvAaMNzv31ZZN/WtGdcK9zJR5blHKdrg4t/9 0WafEdG9rsGng== Message-ID: Date: Mon, 3 Nov 2025 17:15:18 +0100 X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 11/12] x86/xen: use lazy_mmu_state when context-switching To: Kevin Brodsky , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andreas Larsson , Andrew Morton , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , David Hildenbrand , "David S. Miller" , David Woodhouse , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Juergen Gross , "Liam R. Howlett" , Lorenzo Stoakes , Madhavan Srinivasan , Michael Ellerman , Michal Hocko , Mike Rapoport , Nicholas Piggin , Peter Zijlstra , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Vlastimil Babka , Will Deacon , Yeoreum Yun , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, x86@kernel.org References: <20251029100909.3381140-1-kevin.brodsky@arm.com> <20251029100909.3381140-12-kevin.brodsky@arm.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251029100909.3381140-12-kevin.brodsky@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 29.10.25 11:09, Kevin Brodsky wrote: > We currently set a TIF flag when scheduling out a task that is in > lazy MMU mode, in order to restore it when the task is scheduled > again. > > The generic lazy_mmu layer now tracks whether a task is in lazy MMU > mode in task_struct::lazy_mmu_state. We can therefore check that > state when switching to the new task, instead of using a separate > TIF flag. > > Signed-off-by: Kevin Brodsky > --- > arch/x86/include/asm/thread_info.h | 4 +--- > arch/x86/xen/enlighten_pv.c | 3 +-- > 2 files changed, 2 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h > index e71e0e8362ed..0067684afb5b 100644 > --- a/arch/x86/include/asm/thread_info.h > +++ b/arch/x86/include/asm/thread_info.h > @@ -100,8 +100,7 @@ struct thread_info { > #define TIF_FORCED_TF 24 /* true if TF in eflags artificially */ > #define TIF_SINGLESTEP 25 /* reenable singlestep on user return*/ > #define TIF_BLOCKSTEP 26 /* set when we want DEBUGCTLMSR_BTF */ > -#define TIF_LAZY_MMU_UPDATES 27 /* task is updating the mmu lazily */ > -#define TIF_ADDR32 28 /* 32-bit address space on 64 bits */ > +#define TIF_ADDR32 27 /* 32-bit address space on 64 bits */ > > #define _TIF_SSBD BIT(TIF_SSBD) > #define _TIF_SPEC_IB BIT(TIF_SPEC_IB) > @@ -114,7 +113,6 @@ struct thread_info { > #define _TIF_FORCED_TF BIT(TIF_FORCED_TF) > #define _TIF_BLOCKSTEP BIT(TIF_BLOCKSTEP) > #define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP) > -#define _TIF_LAZY_MMU_UPDATES BIT(TIF_LAZY_MMU_UPDATES) > #define _TIF_ADDR32 BIT(TIF_ADDR32) > > /* flags to check in __switch_to() */ > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 4806cc28d7ca..f40f5999352e 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -426,7 +426,6 @@ static void xen_start_context_switch(struct task_struct *prev) > > if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) { > arch_leave_lazy_mmu_mode(); > - set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES); > } > enter_lazy(XEN_LAZY_CPU); > } > @@ -437,7 +436,7 @@ static void xen_end_context_switch(struct task_struct *next) > > xen_mc_flush(); > leave_lazy(XEN_LAZY_CPU); > - if (test_and_clear_ti_thread_flag(task_thread_info(next), TIF_LAZY_MMU_UPDATES)) > + if (next->lazy_mmu_state.active) This is nasty. If in_lazy_mmu_mode() is not sufficient, we will want to have a separate helper that makes it clear what the difference between both variants is. -- Cheers David