From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A982630C631 for ; Mon, 18 May 2026 14:34:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779114894; cv=none; b=ncVgvpBjWJRTCCAJqyOe1jyYLNElXBdHQMJI+iZHbgvQM0VfcJEoaJrejMcI7IW/KE4c33kr45hGLvufDD5wDLWqriL4+MWCZwcIqg3p2ZMNPmMTbwMT3i+B/OY43nHX5WeNGNMI4KrcnfjfDCDq4HrmTjgwIBf70ZtYjJOl1ss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779114894; c=relaxed/simple; bh=E15tHTNDpPdXPrfZ/GjSgBlqQkUxfFvGZeYUSNVaEFs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Yf1ZswdWYz85z8TZNKdlZ7gQcSOWkpGWpsHZdKEHYqT/LZHWMSN5ysYK2JYRLuIOF3WWfrUK47Ami5mFtagWH72P8+TJesqVLgn90KSuYS8rsOnLTXHsOROw29C1C56yiPqMh7t7iLf9gx4lJGnlqf/GX17nv6kmn5AD3GV1pvE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=FfFlZJz/; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="FfFlZJz/" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A280E1C01; Mon, 18 May 2026 07:34:46 -0700 (PDT) Received: from [10.57.34.29] (unknown [10.57.34.29]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D83FA3F85F; Mon, 18 May 2026 07:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1779114891; bh=E15tHTNDpPdXPrfZ/GjSgBlqQkUxfFvGZeYUSNVaEFs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=FfFlZJz/BHU+RUZ+zar+T1XTybkuBlKG+zBJN9Lc0p2TtnrRSAXTy5gi7FXOzeQ11 mY/Lo4+ipdrf3BbwBgP0ZI1ULhXto98trvgvBFvkPDWQ8krOYIxKhkK0OF6SXRXSVc 9yRJlTlnM4EQjE/fv7eFTPVUaa4T8aERFuxVxXy0= Message-ID: <10d4eaed-eaee-47b7-9ccf-7f1931b26b02@arm.com> Date: Mon, 18 May 2026 16:34:41 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/xen: Tolerate nested XEN_LAZY_MMU entering/leaving To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , linux-kernel@vger.kernel.org, x86@kernel.org Cc: marmarek@invisiblethingslab.com, Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , xen-devel@lists.xenproject.org References: <20260508143933.493013-1-jgross@suse.com> <362bc938-18ea-4f6a-938a-893dfb1c956d@arm.com> <36fc4317-d7a0-410c-9d95-28858018053c@suse.com> From: Kevin Brodsky Content-Language: en-GB In-Reply-To: <36fc4317-d7a0-410c-9d95-28858018053c@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09/05/2026 08:32, Jürgen Groß wrote: > On 08.05.26 22:54, Kevin Brodsky wrote: >> On 08/05/2026 16:39, Juergen Gross wrote: >>> With the support of nested lazy mmu sections it can happen that >>> arch_enter_lazy_mmu_mode() is being called twice without a call of >>> arch_leave_lazy_mmu_mode() in between, as the lazy_mmu_*() helpers >>> are not disabling preemption when checking for nested lazy mmu >>> sections. >> >> I think this is a correct description of the issue, i.e. potentially we >> have arch_enter_lazy_mmu_mode() called twice *sequentially*. Therefore I >> don't think that disabling preemption inside arch_enter_lazy_mmu_mode() >> is enough - we have a problem with preemption occurring inside >> lazy_mmu_mode_enable() generally, not necessarily inside >> arch_enter_lazy_mmu_mode(). >> >> Preemption shouldn't matter if commit 291b3abed657 is reverted. AFAICT >> this is the only easy fix. > The description wasn't really complete, I think. > > The double call will only be possible if arch_end_context_switch() is > calling arch_enter_lazy_mmu_mode(), and this is happening for Xen PV > only. > arch_end_context_switch() is a nop for all other cases. Right, agreed. Would be good to update the commit message. > > So this can be handled completely internal of Xen (otherwise a revert of > 291b3abed657 wouldn't help), and it is easy to do so as my patch is > showing. > > As said, I'd like to get rid of the extra tracking by Xen regarding > lazy mode. Got it, that would be best. This patch should ensure that xen_lazy_mode always has the correct value regardless of preemption, which is what matters for Xen. Reviewed-by: Kevin Brodsky