All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Zhen-Hua (USL-China)" <zhen-hual-VXdhtT5mjnY@public.gmane.org>
To: Don Dutile <ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Dan Williams <djbw-b10kYP2dOMg@public.gmane.org>
Subject: Re: [PATCH 1/1] x86/iommu: fix dma pte address size error
Date: Mon, 17 Jun 2013 11:38:37 +0800	[thread overview]
Message-ID: <51BE84BD.6050501@hp.com> (raw)
In-Reply-To: <51BB7A1E.5000605-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi Don,

This patch is not only for the sake of spec interpretation.
Till now I did not see any bugs , but it does not meant no bugs will appear
in the future. The address returned by dma_pte_addr is used in many places.

Thanks
Zhenhua


On 06/15/2013 04:16 AM, Don Dutile wrote:
> On 05/23/2013 08:35 PM, Li, Zhen-Hua wrote:
>> In Intel Vt-D specs, Chapter 9.3 Page-Table Entry,
>> The size of ADDR(address) field is 12:51, but the function dma_pte_addr
>>   treats it as 12:63.
>>
>> Signed-off-by: Li, Zhen-Hua<zhen-hual-VXdhtT5mjnY@public.gmane.org>
>> ---
>>   drivers/iommu/intel-iommu.c   |    4 ++--
>>   include/linux/dma_remapping.h |    2 ++
>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>
>
> Is this patching for the sake of spec interpretation?
> a dma-pte format (consumed by iommu) has 63,61:52 as available for sw, 
> ignored by hw.
> 62 is 'transient mapping' bit, which is a _hint_ for selecting iotlbs 
> to flush sooner.
> finally, the system would have to have a memory map that actually has 
> bit 62 set to
> be affected.
>
> So, for intel-iommu, I don't see a bug occurring.
> Did you actually have one with previous definition, and if so,
> could you provide that information ?
>
> Cheers,
> - Don
>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index b4f0e28..c6d2847 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -311,10 +311,10 @@ static inline void dma_set_pte_prot(struct 
>> dma_pte *pte, unsigned long prot)
>>   static inline u64 dma_pte_addr(struct dma_pte *pte)
>>   {
>>   #ifdef CONFIG_64BIT
>> -    return pte->val&  VTD_PAGE_MASK;
>> +    return pte->val&  DMA_PTE_MASK;
>>   #else
>>       /* Must have a full atomic 64-bit read */
>> -    return  __cmpxchg64(&pte->val, 0ULL, 0ULL)& VTD_PAGE_MASK;
>> +    return  __cmpxchg64(&pte->val, 0ULL, 0ULL)& DMA_PTE_MASK;
>>   #endif
>>   }
>>
>> diff --git a/include/linux/dma_remapping.h 
>> b/include/linux/dma_remapping.h
>> index 57c9a8a..7a1e212 100644
>> --- a/include/linux/dma_remapping.h
>> +++ b/include/linux/dma_remapping.h
>> @@ -16,6 +16,8 @@
>>   #define DMA_PTE_WRITE (2)
>>   #define DMA_PTE_LARGE_PAGE (1<<  7)
>>   #define DMA_PTE_SNP (1<<  11)
>> +#define DMA_PTE_ADD_LENGTH (40)
>> +#define DMA_PTE_MASK    ((((u64)1<<  DMA_PTE_ADD_LENGTH) - 1)<<  
>> VTD_PAGE_SHIFT)
>>
>>   #define CONTEXT_TT_MULTI_LEVEL    0
>>   #define CONTEXT_TT_DEV_IOTLB    1
>
> .
>

WARNING: multiple messages have this Message-ID (diff)
From: "Li, Zhen-Hua (USL-China)" <zhen-hual@hp.com>
To: Don Dutile <ddutile@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Vinod Koul <vinod.koul@intel.com>, Dan Williams <djbw@fb.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] x86/iommu: fix dma pte address size error
Date: Mon, 17 Jun 2013 11:38:37 +0800	[thread overview]
Message-ID: <51BE84BD.6050501@hp.com> (raw)
In-Reply-To: <51BB7A1E.5000605@redhat.com>

Hi Don,

This patch is not only for the sake of spec interpretation.
Till now I did not see any bugs , but it does not meant no bugs will appear
in the future. The address returned by dma_pte_addr is used in many places.

Thanks
Zhenhua


On 06/15/2013 04:16 AM, Don Dutile wrote:
> On 05/23/2013 08:35 PM, Li, Zhen-Hua wrote:
>> In Intel Vt-D specs, Chapter 9.3 Page-Table Entry,
>> The size of ADDR(address) field is 12:51, but the function dma_pte_addr
>>   treats it as 12:63.
>>
>> Signed-off-by: Li, Zhen-Hua<zhen-hual@hp.com>
>> ---
>>   drivers/iommu/intel-iommu.c   |    4 ++--
>>   include/linux/dma_remapping.h |    2 ++
>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>
>
> Is this patching for the sake of spec interpretation?
> a dma-pte format (consumed by iommu) has 63,61:52 as available for sw, 
> ignored by hw.
> 62 is 'transient mapping' bit, which is a _hint_ for selecting iotlbs 
> to flush sooner.
> finally, the system would have to have a memory map that actually has 
> bit 62 set to
> be affected.
>
> So, for intel-iommu, I don't see a bug occurring.
> Did you actually have one with previous definition, and if so,
> could you provide that information ?
>
> Cheers,
> - Don
>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index b4f0e28..c6d2847 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -311,10 +311,10 @@ static inline void dma_set_pte_prot(struct 
>> dma_pte *pte, unsigned long prot)
>>   static inline u64 dma_pte_addr(struct dma_pte *pte)
>>   {
>>   #ifdef CONFIG_64BIT
>> -    return pte->val&  VTD_PAGE_MASK;
>> +    return pte->val&  DMA_PTE_MASK;
>>   #else
>>       /* Must have a full atomic 64-bit read */
>> -    return  __cmpxchg64(&pte->val, 0ULL, 0ULL)& VTD_PAGE_MASK;
>> +    return  __cmpxchg64(&pte->val, 0ULL, 0ULL)& DMA_PTE_MASK;
>>   #endif
>>   }
>>
>> diff --git a/include/linux/dma_remapping.h 
>> b/include/linux/dma_remapping.h
>> index 57c9a8a..7a1e212 100644
>> --- a/include/linux/dma_remapping.h
>> +++ b/include/linux/dma_remapping.h
>> @@ -16,6 +16,8 @@
>>   #define DMA_PTE_WRITE (2)
>>   #define DMA_PTE_LARGE_PAGE (1<<  7)
>>   #define DMA_PTE_SNP (1<<  11)
>> +#define DMA_PTE_ADD_LENGTH (40)
>> +#define DMA_PTE_MASK    ((((u64)1<<  DMA_PTE_ADD_LENGTH) - 1)<<  
>> VTD_PAGE_SHIFT)
>>
>>   #define CONTEXT_TT_MULTI_LEVEL    0
>>   #define CONTEXT_TT_DEV_IOTLB    1
>
> .
>


  parent reply	other threads:[~2013-06-17  3:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24  0:35 [PATCH 1/1] x86/iommu: fix dma pte address size error Li, Zhen-Hua
2013-05-24  0:35 ` Li, Zhen-Hua
     [not found] ` <1369355756-1030-1-git-send-email-zhen-hual-VXdhtT5mjnY@public.gmane.org>
2013-06-13  0:43   ` ZhenHua
2013-06-13  0:43     ` ZhenHua
2013-06-14 20:16   ` Don Dutile
2013-06-14 20:16     ` Don Dutile
     [not found]     ` <51BB7A1E.5000605-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-06-17  3:38       ` Li, Zhen-Hua (USL-China) [this message]
2013-06-17  3:38         ` Li, Zhen-Hua (USL-China)
  -- strict thread matches above, loose matches on Subject: below --
2013-05-23  7:52 Li, Zhen-Hua
2013-05-23  7:52 ` Li, Zhen-Hua

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51BE84BD.6050501@hp.com \
    --to=zhen-hual-vxdhtt5mjny@public.gmane.org \
    --cc=ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=djbw-b10kYP2dOMg@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.