On Thu, 2016-11-10 at 11:45 +0100, Joerg Roedel wrote:
> Hi David,
>
> On Sun, Oct 30, 2016 at 06:18:22AM -0600, David Woodhouse wrote:
> > + /* Start at 2 because it's defined as 1^(1+PSS) */
>
> This probably means 2^(1+PSS), right?
Or 1 << (1+PSS). Yeah.
> > + iommu->pasid_max = 2
On Thu, 2016-11-10 at 11:45 +0100, Joerg Roedel wrote:
> Hi David,
>
> On Sun, Oct 30, 2016 at 06:18:22AM -0600, David Woodhouse wrote:
> > + /* Start at 2 because it's defined as 1^(1+PSS) */
>
> This probably means 2^(1+PSS), right?
Or 1 << (1+PSS). Yeah.
> > + iommu->pasid_max = 2
Hi David,
On Sun, Oct 30, 2016 at 06:18:22AM -0600, David Woodhouse wrote:
> + /* Start at 2 because it's defined as 1^(1+PSS) */
This probably means 2^(1+PSS), right?
> + iommu->pasid_max = 2 << ecap_pss(iommu->ecap);
Otherwise the patch looks good. Do you want to send it upstream
Hi David,
On Sun, Oct 30, 2016 at 06:18:22AM -0600, David Woodhouse wrote:
> + /* Start at 2 because it's defined as 1^(1+PSS) */
This probably means 2^(1+PSS), right?
> + iommu->pasid_max = 2 << ecap_pss(iommu->ecap);
Otherwise the patch looks good. Do you want to send it upstream
On 2016/10/30 at 20:18, David Woodhouse wrote:
> On Wed, 2016-10-12 at 13:17 +0100, David Woodhouse wrote:
>> Yes, that looks correct. I think we may also need to limit it, because
>> full 20-bit PASID support means we'll attempt an order 11 allocation.
>> But that's certainly correct for now
>
On 2016/10/30 at 20:18, David Woodhouse wrote:
> On Wed, 2016-10-12 at 13:17 +0100, David Woodhouse wrote:
>> Yes, that looks correct. I think we may also need to limit it, because
>> full 20-bit PASID support means we'll attempt an order 11 allocation.
>> But that's certainly correct for now
>
On Wed, 2016-10-12 at 13:17 +0100, David Woodhouse wrote:
> Yes, that looks correct. I think we may also need to limit it, because
> full 20-bit PASID support means we'll attempt an order 11 allocation.
> But that's certainly correct for now
Actually, not quite correct. You fixed the allocation
On Wed, 2016-10-12 at 13:17 +0100, David Woodhouse wrote:
> Yes, that looks correct. I think we may also need to limit it, because
> full 20-bit PASID support means we'll attempt an order 11 allocation.
> But that's certainly correct for now
Actually, not quite correct. You fixed the allocation
On Mon, 2016-09-19 at 14:18 +0200, Joerg Roedel wrote:
> [Cc'ing David]
>
> On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
> >
> > According to the vt-d spec, the size of pasid (state) entry is 8B
> > which equals 3 in power of 2, the number of pasid (state) entries
> > is
On Mon, 2016-09-19 at 14:18 +0200, Joerg Roedel wrote:
> [Cc'ing David]
>
> On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
> >
> > According to the vt-d spec, the size of pasid (state) entry is 8B
> > which equals 3 in power of 2, the number of pasid (state) entries
> > is
Ping David for confirmation
On 2016/09/19 at 20:18, Joerg Roedel wrote:
> [Cc'ing David]
>
> On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
>> According to the vt-d spec, the size of pasid (state) entry is 8B
>> which equals 3 in power of 2, the number of pasid (state) entries
>> is
Ping David for confirmation
On 2016/09/19 at 20:18, Joerg Roedel wrote:
> [Cc'ing David]
>
> On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
>> According to the vt-d spec, the size of pasid (state) entry is 8B
>> which equals 3 in power of 2, the number of pasid (state) entries
>> is
[Cc'ing David]
On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
> According to the vt-d spec, the size of pasid (state) entry is 8B
> which equals 3 in power of 2, the number of pasid (state) entries
> is (ecap_pss + 1) in power of 2.
>
> Thus the right size of pasid (state) table in
[Cc'ing David]
On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
> According to the vt-d spec, the size of pasid (state) entry is 8B
> which equals 3 in power of 2, the number of pasid (state) entries
> is (ecap_pss + 1) in power of 2.
>
> Thus the right size of pasid (state) table in
According to the vt-d spec, the size of pasid (state) entry is 8B
which equals 3 in power of 2, the number of pasid (state) entries
is (ecap_pss + 1) in power of 2.
Thus the right size of pasid (state) table in power of 2 should be
ecap_pss(iommu->ecap) plus "1+3=4" other than 7.
Signed-off-by:
According to the vt-d spec, the size of pasid (state) entry is 8B
which equals 3 in power of 2, the number of pasid (state) entries
is (ecap_pss + 1) in power of 2.
Thus the right size of pasid (state) table in power of 2 should be
ecap_pss(iommu->ecap) plus "1+3=4" other than 7.
Signed-off-by:
16 matches
Mail list logo
