Re: Support SVM without PASID - Jean-Philippe Brucker

From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>
Cc: valmiki <valmikibow@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Lan, Tianyu" <tianyu.lan@intel.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Support SVM without PASID
Date: Mon, 14 Aug 2017 10:07:12 +0100	[thread overview]
Message-ID: <2a8c13cb-ecca-1138-71c9-f923eaf08641@arm.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190D716A4@SHSMSX101.ccr.corp.intel.com>

On 14/08/17 09:00, Tian, Kevin wrote:
>> 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.

Yes, nested translation is just a tool, it doesn't have to be dedicated to
virtualization.

> 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). :-)

I also can't come up with a convincing API for setting up the second stage
from userspace. Hopefully we can ignore this case for the moment :)

Thanks,
Jean