From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs Date: Thu, 1 Apr 2021 09:12:39 -0300 Message-ID: <20210401121239.GB1463678@nvidia.com> References: <20210322120300.GU2356281@nvidia.com> <20210324120528.24d82dbd@jacob-builder> <20210329163147.GG2356281@nvidia.com> <20210330132830.GO2356281@nvidia.com> <20210331124038.GE1463678@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0SxDW66bzJySId9P/AAnAjijo99XEGeaWorQyE7VnhE=; b=ovKIIBBWR753aRzH9COKDHr4d771vCi+CfgK6ryiK9xRjit9rFnvntefNPw8oI8TSWtWGysQUhIBNx7MbeBSW3Ba3/xeDK0ICPL0OKeIihRVHiThxwSGPUJCMYMho/5t64Pm697aIxSKb3nhBIG1NUXEtYD9mGNk0AOgtHQOXnt8iYa0MjxkKbwqq5bXZg2Xqn7uZVPzp7+7hkJ8Y0p2L7tGPR4p80gmZoLCsFY5etwC/lrp63BjkHvhOJTUAbrz58Xn8pJCcnG70ACtUEG5+Wf561cx1DvNEjUwa01MsLR7nqW9+uJxNNSMOdCJ2EQ1w3klbOnrA4GNJoLgSr5mWw== Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Sender: "iommu" To: Jean-Philippe Brucker Cc: "Tian, Kevin" , Alex Williamson , "Raj, Ashok" , Jonathan Corbet , Jean-Philippe Brucker , Li Zefan , LKML , "Jiang, Dave" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Johannes Weiner , Tejun Heo , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Wu, Hao" , David Woodhouse On Thu, Apr 01, 2021 at 02:05:00PM +0200, Jean-Philippe Brucker wrote: > On Thu, Apr 01, 2021 at 07:04:01AM +0000, Liu, Yi L wrote: > > > - how about AMD and ARM's vSVA support? Their PASID allocation and page > > > table > > > happens within guest. They only need to bind the guest PASID table to > > > host. > > In this case each VM has its own IOASID space, and the host IOASID > allocator doesn't participate. Plus this only makes sense when assigning a > whole VF to a guest, and VFIO is the tool for this. So I wouldn't shoehorn > those ops into /dev/ioasid, though we do need a transport for invalidate > commands. How does security work? Devices still have to be authorized to use the PASID and this approach seems like it completely excludes mdev/vdpa from ever using a PASID, and those are the most logical users. > > > Above model seems unable to fit them. (Jean, Eric, Jacob please feel free > > > to correct me) > > > - this per-ioasid SVA operations is not aligned with the native SVA usage > > > model. Native SVA bind is per-device. > > Bare-metal SVA doesn't need /dev/ioasid either. It depends what you are doing. /dev/ioasid would provide fine grained control over the memory mapping. It is not strict SVA, but I can see applications where using a GPU with a pre-configured optimized mapping could be interesting. > A program uses a device handle to either ask whether SVA is enabled, > or to enable it explicitly. With or without /dev/ioasid, that step > is required. OpenCL uses the first method - automatically enable > "fine-grain system SVM" if available, and provide a flag to > userspace. SVA can be done with ioasid, we can decide if it makes sense to have shortcuts in every driver > So userspace does not need to know about PASID. It's only one method for > doing SVA (some GPUs are context-switching page tables instead). Sure, there are lots of approaches. Here we are only talking about PASID enablement. PASID has more options. > * Page faults, page response. From and to devices, and don't necessarily > have a PASID. But needed by vdpa as well, so that's also going through > /dev/ioasid? Only real PASID's should use this interface. All the not-PASID stuff is on its own. VPDA should accept a PASID from here and configure&authorize the real HW to attach the PASID to all DMA's connected to the virtio queues. Jason