> From: Christian König
> Sent: Friday, September 7, 2018 4:56 PM
>
> 5. It would be nice to have to allocate multiple PASIDs for the same
> process address space.
> E.g. some teams at AMD want to use a separate GPU address space
> for their userspace client library. I'm still trying to a
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Saturday, September 8, 2018 5:25 AM
> > > iommu-sva expects everywhere that the device has an iommu_domain,
> > > it's the first thing we check on entry. Bypassing all of this would
> > > call idr_alloc() directly, and wouldn't have a
Am 12.09.2018 um 14:40 schrieb Jean-Philippe Brucker:
On 08/09/2018 08:29, Christian König wrote:
Yes, exactly. I just need a PASID which is never used by the OS for a
process and we can easily give that back when the last FD reference is
closed.
Alright, iommu-sva can get its PASID from this e
On 08/09/2018 08:29, Christian König wrote:
> Yes, exactly. I just need a PASID which is never used by the OS for a
> process and we can easily give that back when the last FD reference is
> closed.
Alright, iommu-sva can get its PASID from this external allocator as
well, as long as it has an i
Am 07.09.2018 um 23:25 schrieb Jacob Pan:
On Fri, 7 Sep 2018 20:02:54 +0200
Christian König wrote:
[SNIP]
iommu-sva expects everywhere that the device has an iommu_domain,
it's the first thing we check on entry. Bypassing all of this would
call idr_alloc() directly, and wouldn't have any code
On Fri, 7 Sep 2018 20:02:54 +0200
Christian König wrote:
> Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker:
> > On 07/09/2018 09:55, Christian König wrote:
> >> I will take this as an opportunity to summarize some of the
> >> requirements we have for PASID management from the amdgpu driver
Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker:
On 07/09/2018 09:55, Christian König wrote:
I will take this as an opportunity to summarize some of the requirements
we have for PASID management from the amdgpu driver point of view:
That's incredibly useful, thanks :)
1. We need to be ab
On 07/09/2018 09:55, Christian König wrote:
> I will take this as an opportunity to summarize some of the requirements
> we have for PASID management from the amdgpu driver point of view:
That's incredibly useful, thanks :)
> 1. We need to be able to allocate PASID between 1 and some maximum. Ze
Am 06.09.2018 um 14:45 schrieb Jean-Philippe Brucker:
On 06/09/2018 12:12, Christian König wrote:
Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker:
Hi Eric,
Thanks for reviewing
On 05/09/2018 12:29, Auger Eric wrote:
+int iommu_sva_device_init(struct device *dev, unsigned long features,
On 06/09/2018 12:12, Christian König wrote:
> Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker:
>> Hi Eric,
>>
>> Thanks for reviewing
>>
>> On 05/09/2018 12:29, Auger Eric wrote:
+int iommu_sva_device_init(struct device *dev, unsigned long features,
+ unsigned int max_pa
Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker:
Hi Eric,
Thanks for reviewing
On 05/09/2018 12:29, Auger Eric wrote:
+int iommu_sva_device_init(struct device *dev, unsigned long features,
+ unsigned int max_pasid)
what about min_pasid?
No one asked for it... The
Hi Eric,
Thanks for reviewing
On 05/09/2018 12:29, Auger Eric wrote:
>> +int iommu_sva_device_init(struct device *dev, unsigned long features,
>> + unsigned int max_pasid)
> what about min_pasid?
No one asked for it... The max_pasid parameter is here for drivers that
have ve
Hi Jean-Philippe,
On 05/11/2018 09:06 PM, Jean-Philippe Brucker wrote:
> Shared Virtual Addressing (SVA) provides a way for device drivers to bind
> process address spaces to devices. This requires the IOMMU to support page
> table format and features compatible with the CPUs, and usually requires
On Thu, 17 May 2018 11:02:02 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> Thanks for reviewing this
>
> On 16/05/18 21:41, Jacob Pan wrote:
> [...]
> > seems the min_pasid never gets used. do you really need it?
>
> Yes, the SMMU sets it to 1 in patch 28/40, because it needs to rese
Hi Jacob,
Thanks for reviewing this
On 16/05/18 21:41, Jacob Pan wrote:
>> + * The device must support multiple address spaces (e.g. PCI PASID).
>> By default
>> + * the PASID allocated during bind() is limited by the IOMMU
>> capacity, and by
>> + * the device PASID width defined in the PCI capa
On Fri, 11 May 2018 20:06:02 +0100
Jean-Philippe Brucker wrote:
> Shared Virtual Addressing (SVA) provides a way for device drivers to
> bind process address spaces to devices. This requires the IOMMU to
> support page table format and features compatible with the CPUs, and
> usually requires the
Shared Virtual Addressing (SVA) provides a way for device drivers to bind
process address spaces to devices. This requires the IOMMU to support page
table format and features compatible with the CPUs, and usually requires
the system to support I/O Page Faults (IOPF) and Process Address Space ID
(PA
17 matches
Mail list logo
