> From: Bharat Kumar Gogada [mailto:bhara...@xilinx.com]
> Sent: Monday, August 28, 2017 9:10 PM
>
> > Subject: RE: Support SVM without PASID
> >
> > > From: valmiki [mailto:valmiki...@gmail.com]
> > > Sent: Saturday, August 12, 2017 8:11 PM
> > >
> Subject: RE: Support SVM without PASID
>
> > From: valmiki [mailto:valmiki...@gmail.com]
> > Sent: Saturday, August 12, 2017 8:11 PM
> >
> > On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote:
> > > On 05/08/17 06:14, valmiki wrote:
> > > [...]
&g
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-s
> 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 devi
> From: valmiki [mailto:valmiki...@gmail.com]
> Sent: Saturday, August 12, 2017 8:11 PM
>
> On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote:
> > On 05/08/17 06:14, valmiki wrote:
> > [...]
> >> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
> >> documentation we fill vaddr and
On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote:
On 05/08/17 06:14, valmiki wrote:
[...]
Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
and pass them to VFIO. But if we use dynamic allocation in applic
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 de
On 2017/8/11 14:41, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
>> Sent: Monday, August 7, 2017 8:52 PM
>>
>> Hi Bob,
>>
>> On 07/08/17 13:18, Bob Liu wrote:
>>> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
On 05/08/17 06:14, valmiki wrote:
On 11/08/17 07:41, Tian, Kevin wrote:
[...]
>>> Hi Jean,
>>>
>>> I think there is another way to support SVM without PASID.
>>>
>>> Suppose there is a device in the same SOC-chip, the device access memory
>> through SMMU(using internal bus instead of PCIe)
>>> Once page fault, the device send an ev
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Monday, August 7, 2017 8:52 PM
>
> Hi Bob,
>
> On 07/08/17 13:18, Bob Liu wrote:
> > On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
> >> On 05/08/17 06:14, valmiki wrote:
> >> [...]
> >>> Hi Jean, Thanks a lot, now i un
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Friday, August 4, 2017 5:43 PM
>
> Hi Kevin,
>
> On 04/08/17 02:49, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Tuesday, August 1, 2017 4:26 PM
> >>
> >> It depends what type you use when registering t
On 08/08/17 01:51, Bob Liu wrote:
> On 2017/8/7 20:52, Jean-Philippe Brucker wrote:
>> Hi Bob,
>>
>> On 07/08/17 13:18, Bob Liu wrote:
>>> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
On 05/08/17 06:14, valmiki wrote:
[...]
> Hi Jean, Thanks a lot, now i understood the flow. From v
On 2017/8/7 20:52, Jean-Philippe Brucker wrote:
> Hi Bob,
>
> On 07/08/17 13:18, Bob Liu wrote:
>> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
>>> On 05/08/17 06:14, valmiki wrote:
>>> [...]
Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
documentation we fill vadd
Hi Bob,
On 07/08/17 13:18, Bob Liu wrote:
> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
>> On 05/08/17 06:14, valmiki wrote:
>> [...]
>>> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
>>> documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
>>> and pass
On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
> On 05/08/17 06:14, valmiki wrote:
> [...]
>> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
>> documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
>> and pass them to VFIO. But if we use dynamic allocation in
On 05/08/17 06:14, valmiki wrote:
[...]
> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
> documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
> and pass them to VFIO. But if we use dynamic allocation in application
> (say malloc), do we need to use dma API t
On 8/2/2017 12:10 AM, Jean-Philippe Brucker wrote:
On 01/08/17 18:38, valmiki wrote:
[...]
So i digged through your patches and i understood that using BIND ioctls
satge-1 translations are setup in SMMU for an application.
If we use VFIO_IOMMU_MAP/UNMAP_DMA ioctls they are setting up stage-2
tra
Hi Kevin,
On 04/08/17 02:49, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Tuesday, August 1, 2017 4:26 PM
>>
>> It depends what type you use when registering the IOMMU with
>> VFIO_SET_IOMMU:
>>
>> * If the type is VFIO_TYPE1v2_IOMMU, then
>> VFIO_IOMMU_MAP/UNMAP_DMA
>> affects the
> From: Jean-Philippe Brucker
> Sent: Tuesday, August 1, 2017 4:26 PM
>
> It depends what type you use when registering the IOMMU with
> VFIO_SET_IOMMU:
>
> * If the type is VFIO_TYPE1v2_IOMMU, then
> VFIO_IOMMU_MAP/UNMAP_DMA
> affects the stage-1 non-PASID context (already the case in mainline
On 01/08/17 18:38, valmiki wrote:
[...]
>>> So i digged through your patches and i understood that using BIND ioctls
>>> satge-1 translations are setup in SMMU for an application.
>>> If we use VFIO_IOMMU_MAP/UNMAP_DMA ioctls they are setting up stage-2
>>> translations in SMMU.
>>> So without PASI
On 8/1/2017 1:56 PM, Jean-Philippe Brucker wrote:
Hi Valmiki,
Sorry for the delay, I was away last week.
On 22/07/17 03:05, valmiki wrote:
On 7/12/2017 10:18 PM, Jean-Philippe Brucker wrote:
On 12/07/17 17:27, valmiki wrote:
On 7/11/2017 4:26 PM, Jean-Philippe Brucker wrote:
Hi Valmiki,
On
Hi Valmiki,
Sorry for the delay, I was away last week.
On 22/07/17 03:05, valmiki wrote:
> On 7/12/2017 10:18 PM, Jean-Philippe Brucker wrote:
>> On 12/07/17 17:27, valmiki wrote:
>>> On 7/11/2017 4:26 PM, Jean-Philippe Brucker wrote:
Hi Valmiki,
On 09/07/17 04:15, valmiki wrote:
>
On 7/12/2017 10:18 PM, Jean-Philippe Brucker wrote:
On 12/07/17 17:27, valmiki wrote:
On 7/11/2017 4:26 PM, Jean-Philippe Brucker wrote:
Hi Valmiki,
On 09/07/17 04:15, valmiki wrote:
Hi,
In SMMUv3 architecture document i see "PASIDs are optional,
configurable, and of a size determined by the
On 12/07/17 17:27, valmiki wrote:
> On 7/11/2017 4:26 PM, Jean-Philippe Brucker wrote:
>> Hi Valmiki,
>>
>> On 09/07/17 04:15, valmiki wrote:
> Hi,
>
> In SMMUv3 architecture document i see "PASIDs are optional,
> configurable, and of a size determined by the minimum
> of the en
On 7/11/2017 4:26 PM, Jean-Philippe Brucker wrote:
Hi Valmiki,
On 09/07/17 04:15, valmiki wrote:
Hi,
In SMMUv3 architecture document i see "PASIDs are optional,
configurable, and of a size determined by the minimum
of the endpoint".
So if PASID's are optional and not supported by PCIe end poi
On 7/11/2017 1:01 AM, Jerome Glisse wrote:
On Sun, Jul 09, 2017 at 08:45:57AM +0530, valmiki wrote:
Hi,
In SMMUv3 architecture document i see "PASIDs are optional,
configurable, and of a size determined by the minimum
of the endpoint".
So if PASID's are optional and not supported by PCIe end p
Hi Valmiki,
On 09/07/17 04:15, valmiki wrote:
>>> Hi,
>>>
>>> In SMMUv3 architecture document i see "PASIDs are optional,
>>> configurable, and of a size determined by the minimum
>>> of the endpoint".
>>>
>>> So if PASID's are optional and not supported by PCIe end point, how SVM
>>> can be achie
On Sun, Jul 09, 2017 at 08:45:57AM +0530, valmiki wrote:
> > > Hi,
> > >
> > > In SMMUv3 architecture document i see "PASIDs are optional,
> > > configurable, and of a size determined by the minimum
> > > of the endpoint".
> > >
> > > So if PASID's are optional and not supported by PCIe end point
On 2017/7/9 11:15, valmiki wrote:
>>> Hi,
>>>
>>> In SMMUv3 architecture document i see "PASIDs are optional,
>>> configurable, and of a size determined by the minimum
>>> of the endpoint".
>>>
>>> So if PASID's are optional and not supported by PCIe end point, how SVM
>>> can be achieved ?
>>
>> I
x-...@vger.kernel.org;
> iommu@lists.linux-foundation.org;
> Pan, Jacob jun
> Subject: Re: Support SVM without PASID
>
> >> Hi,
> >>
> >> In SMMUv3 architecture document i see "PASIDs are optional,
> >> configurable, and of a size determined by t
Hi,
In SMMUv3 architecture document i see "PASIDs are optional,
configurable, and of a size determined by the minimum
of the endpoint".
So if PASID's are optional and not supported by PCIe end point, how SVM
can be achieved ?
It cannot be inferred from that statement that PASID support is not
On Sat, 8 Jul 2017 22:33:01 +0530
valmiki wrote:
> Hi,
>
> In SMMUv3 architecture document i see "PASIDs are optional,
> configurable, and of a size determined by the minimum
> of the endpoint".
>
> So if PASID's are optional and not supported by PCIe end point, how SVM
> can be achieved ?
I
32 matches
Mail list logo
