From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 814F72D47FF for ; Wed, 22 Oct 2025 05:10:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761109859; cv=none; b=uDTRFrUOgDwLDvVGA0hgyWdkQsjHqCva7gHfvJNAWk3Mvg43aWUF59vukPNXRYOIYV3Vo0Abms+tJSilZncO/eWMut02IXmJNtIVz9txh4/ZDbzM6EmAhTB7A/AHhtiltqT6UsWp1H157fH0HI/WgtEhN5VwJTDmS+4IlexTbWM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761109859; c=relaxed/simple; bh=sa3pkvNdt3+2ieOyDtANYF05yDX/GehSlt5KkTBOpIk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WNcFLLdSl7aK9OzmaTlbRAAALZPoPJh9iqAH5EemzwNg0MKu1kfuwTnr66GijKSAv/RqWScdR+eGJX6cb60mupPJQ1TLi05A+TGtmBkRkhbiCNTUQNOYlMsIQmL5xtuxstDa0welrXkWjlME4Um8S8Oluw5MH2UQ7FPt+tIRnrI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PNEs+/E7; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PNEs+/E7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761109858; x=1792645858; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=sa3pkvNdt3+2ieOyDtANYF05yDX/GehSlt5KkTBOpIk=; b=PNEs+/E7mAx1hLMw1sdG5tXgVJKSAaLsFGI0QWei06J06P7Rrr0v33wA ML6Ix6oTwc9FMoH87Z1w+JE2K/g7XtT909Lg11ws/3UQn7XnDE+Q7PgDF 3gzx/WuzU1IK1v7QvdJO2h8VjVtBDyiSUPrQYpwnjp0ZTjk+aMjUK+5Fp m7S2pMqxiYqWl3Oh1CMF1KurYyteK3JBDGiHz/wx4L3kBy17MEaWB4vjx gXCSXhXiaSwEfnTaFvDeY5kiuBE3u6WQnwdc26zSwRIkZu0pvMfPshg0t ozCZcyi94XW3pA5bby6ZV1ZwUe6WTFlwiDOdwkBJq6wSItIp6r22NZzmM Q==; X-CSE-ConnectionGUID: 0Nva7rDbSkadkFt8dC3zXQ== X-CSE-MsgGUID: nJ4eEhz+Se63JtPANMfl7g== X-IronPort-AV: E=McAfee;i="6800,10657,11586"; a="63286688" X-IronPort-AV: E=Sophos;i="6.19,246,1754982000"; d="scan'208";a="63286688" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2025 22:10:57 -0700 X-CSE-ConnectionGUID: dxfXMIS5SPWjB3eWAnIlqA== X-CSE-MsgGUID: DjyR4X0YT/ijS4596uZPJw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,246,1754982000"; d="scan'208";a="214718411" Received: from allen-sbox.sh.intel.com (HELO [10.239.159.30]) ([10.239.159.30]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2025 22:10:50 -0700 Message-ID: <16775184-a98b-40dc-8fb7-168f90edb427@linux.intel.com> Date: Wed, 22 Oct 2025 13:06:58 +0800 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 v6 0/7] Fix stale IOTLB entries for kernel address space To: Vinicius Costa Gomes , Dave Hansen , Jason Gunthorpe Cc: Andrew Morton , Joerg Roedel , Will Deacon , Robin Murphy , Kevin Tian , Jann Horn , Vasant Hegde , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Alistair Popple , Peter Zijlstra , Uladzislau Rezki , Jean-Philippe Brucker , Andy Lutomirski , Yi Lai , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Michal Hocko , Matthew Wilcox , iommu@lists.linux.dev, security@kernel.org, x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Jiang, Dave" References: <20251014130437.1090448-1-baolu.lu@linux.intel.com> <20251014174339.c7b7d2cfb9f60d225e4fe5ec@linux-foundation.org> <6b187b20-6017-4f85-93ac-529d5df33aa2@linux.intel.com> <11cad2be-9402-4d45-8d2b-c92d8962edfc@linux.intel.com> <20251017140101.GM3901471@nvidia.com> <87zf9pjsg5.fsf@intel.com> Content-Language: en-US From: Baolu Lu In-Reply-To: <87zf9pjsg5.fsf@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/18/25 02:26, Vinicius Costa Gomes wrote: > Dave Hansen writes: > >> On 10/17/25 07:01, Jason Gunthorpe wrote: >>>>> The other alternative is to have arch_vmap_pmd_supported() return false >>>>> when SVA is active, or maybe when it's supported on the platform. >>>>> >>>>> Either of those are 10-ish lines of code and easy to backport. >>>> Hi iommu folks, any insights on this? >>> IDK, the only SVA user on x86 I know is IDXD, so if you do the above >>> plan you break IDXD in all stable kernels. Doesn't sound OK? >> Vinicius, any thoughts on this? >> > This won't break IDXD exactly/totally, it would cause it to be > impossible for users to create shared DSA/IAA workqueues (which are the > nicer ones to use), and it will cause the driver to print some not happy > messages in the kernel logs. The in-kernel users of IDXD (iaa_crypto for > zswap, for example) will continue to work. > > In short, I am not happy, but I think it's workable, even better if > there are alternatives in case people complain. Okay, so I will add an extra patch to disable SVA for x86 arch and re- enable it after the kernel page table free callback is done. Thanks, baolu