[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200401135848.GH882512@myrica>
Date: Wed, 1 Apr 2020 15:58:48 +0200
From: Jean-Philippe Brucker <jean-philippe@...aro.org>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc: Joerg Roedel <joro@...tes.org>,
Alex Williamson <alex.williamson@...hat.com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
iommu@...ts.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
David Woodhouse <dwmw2@...radead.org>,
Jean-Philippe Brucker <jean-philippe@...aro.com>,
Yi Liu <yi.l.liu@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
Raj Ashok <ashok.raj@...el.com>,
Christoph Hellwig <hch@...radead.org>,
Jonathan Cameron <jic23@...nel.org>,
Eric Auger <eric.auger@...hat.com>
Subject: Re: [PATCH 07/10] iommu/ioasid: Use mutex instead of spinlock
On Wed, Mar 25, 2020 at 10:55:28AM -0700, Jacob Pan wrote:
> Each IOASID or set could have multiple users with its own HW context
> to maintain. Often times access to the HW context requires thread context.
> For example, consumers of IOASIDs can register notification blocks to
> sync up its states. Having an atomic notifier is not feasible for these
> update operations.
>
> This patch converts allocator lock from spinlock to mutex in preparation
> for IOASID notifier.
Unfortunately this doesn't work for SVA, which needs to call ioasid_free()
from the RCU callback of mmu_notifier_put(), which cannot sleep. We're
relying on MMU notifers this way to ensure that there is a single IOASID
per mm.
Thanks,
Jean
Powered by blists - more mailing lists