[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YDgh53AcQHT+T3L0@otcwcpicx3.sc.intel.com>
Date: Thu, 25 Feb 2021 22:17:11 +0000
From: Fenghua Yu <fenghua.yu@...el.com>
To: Jean-Philippe Brucker <jean-philippe@...aro.org>
Cc: Joerg Roedel <joro@...tes.org>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Jacob Jun Pan <jacob.jun.pan@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
iommu@...ts.linux-foundation.org, zhangfei.gao@...mail.com,
linux-mm@...ck.org
Subject: Re: [PATCH v6 08/12] fork: Clear PASID for new mm
Hi, Jean,
On Wed, Feb 24, 2021 at 11:19:27AM +0100, Jean-Philippe Brucker wrote:
> Hi Fenghua,
>
> [Trimmed the Cc list]
>
> On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote:
> > When a new mm is created, its PASID should be cleared, i.e. the PASID is
> > initialized to its init state 0 on both ARM and X86.
>
> I just noticed this patch was dropped in v7, and am wondering whether we
> could still upstream it. Does x86 need a child with a new address space
> (!CLONE_VM) to inherit the PASID of the parent? That doesn't make much
> sense with regard to IOMMU structures - same PASID indexing multiple PGDs?
You are right: x86 should clear mm->pasid when a new mm is created.
This patch somehow is losted:(
>
> Currently iommu_sva_alloc_pasid() assumes mm->pasid is always initialized
> to 0 and fails on forked tasks. I'm trying to figure out how to fix this.
> Could we clear the pasid on fork or does it break the x86 model?
x86 calls ioasid_alloc() instead of iommu_sva_alloc_pasid(). So
functionality is not a problem without this patch on x86. But I think
we do need to have this patch in the kernel because PASID is per addr
space and two addr spaces shouldn't have the same PASID.
Who will accept this patch?
Thanks.
-Fenghua
Powered by blists - more mailing lists