From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com ([134.134.136.65]:36872 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752064AbdHNIAZ (ORCPT ); Mon, 14 Aug 2017 04:00:25 -0400 From: "Tian, Kevin" To: "Raj, Ashok" , Jean-Philippe Brucker CC: valmiki , Alex Williamson , "Lan, Tianyu" , "linux-pci@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "Pan, Jacob jun" , "kvm@vger.kernel.org" , "Raj, Ashok" Subject: RE: Support SVM without PASID Date: Mon, 14 Aug 2017 08:00:19 +0000 Message-ID: References: <20170708140257.2de02d63@w520.home> <73619426-6fcc-21ce-cfd4-8c66bde63f9a@gmail.com> <41333a03-bf91-1152-4779-6579845609f6@gmail.com> <564ba70b-db95-7fe0-86bb-bb4eefcd87ec@arm.com> <20170811162506.GB41059@otc-nc-03> In-Reply-To: <20170811162506.GB41059@otc-nc-03> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org List-ID: > From: Raj, Ashok > Sent: Saturday, August 12, 2017 12:25 AM > > On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote: > > Hi Kevin, > > > > > > Consider the situation where a userspace driver (no virtualization) is > > built in a client-server fashion: the server controls a device and spawns > > new processes (clients), each sharing a context with the device using its > > own PASID. If the server wants to hide parts of the client address space > > Just to be sure, you are't expecting the PASID's to be duplicated or > recreated after a new process is spawned. I would expect each process to > get its own PASID by doing a bind. Threads of the same process would be > sharing the same PASID since they all share the same first level > mappings. > > > > from the device (e.g. .text), then it could control stage-2 via MAP/UNMAP > > to restrict the address space. > > I'm confused.. maybe this is different from Intel IOMMU. the first level > requiring a second level is only true when virtualization is in play. > > First level is gVA->gPA, and second level is gPA->hPA (sort of the cloned > EPT map that is setup via VFIO to set up second level) > > When you are in native user application, there is no nesting between first > and second level. The first level is directly VA->hPA. There is no need > for a nested walk in this case? > Strictly speaking nesting is just a hardware capability while virtualization is an use case using that capability. As long as some software entity (not hypervisor) can setup two level page tables, it should just work regardless of how the intermediate address is called. I think Jean is trying to come up a non-virtualization usage using nesting. Of course current example that he illustrated is not very meaningful (as I replied in another mail). :-) Thanks Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: RE: Support SVM without PASID Date: Mon, 14 Aug 2017 08:00:19 +0000 Message-ID: References: <20170708140257.2de02d63@w520.home> <73619426-6fcc-21ce-cfd4-8c66bde63f9a@gmail.com> <41333a03-bf91-1152-4779-6579845609f6@gmail.com> <564ba70b-db95-7fe0-86bb-bb4eefcd87ec@arm.com> <20170811162506.GB41059@otc-nc-03> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "Lan, Tianyu" , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "Pan, Jacob jun" To: "Raj, Ashok" , Jean-Philippe Brucker Return-path: In-Reply-To: <20170811162506.GB41059@otc-nc-03> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: kvm.vger.kernel.org > From: Raj, Ashok > Sent: Saturday, August 12, 2017 12:25 AM > > On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote: > > Hi Kevin, > > > > > > Consider the situation where a userspace driver (no virtualization) is > > built in a client-server fashion: the server controls a device and spawns > > new processes (clients), each sharing a context with the device using its > > own PASID. If the server wants to hide parts of the client address space > > Just to be sure, you are't expecting the PASID's to be duplicated or > recreated after a new process is spawned. I would expect each process to > get its own PASID by doing a bind. Threads of the same process would be > sharing the same PASID since they all share the same first level > mappings. > > > > from the device (e.g. .text), then it could control stage-2 via MAP/UNMAP > > to restrict the address space. > > I'm confused.. maybe this is different from Intel IOMMU. the first level > requiring a second level is only true when virtualization is in play. > > First level is gVA->gPA, and second level is gPA->hPA (sort of the cloned > EPT map that is setup via VFIO to set up second level) > > When you are in native user application, there is no nesting between first > and second level. The first level is directly VA->hPA. There is no need > for a nested walk in this case? > Strictly speaking nesting is just a hardware capability while virtualization is an use case using that capability. As long as some software entity (not hypervisor) can setup two level page tables, it should just work regardless of how the intermediate address is called. I think Jean is trying to come up a non-virtualization usage using nesting. Of course current example that he illustrated is not very meaningful (as I replied in another mail). :-) Thanks Kevin