* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-10-04 15:13 ` Alexander Duyck
0 siblings, 0 replies; 17+ messages in thread
From: Alexander Duyck @ 2018-10-04 15:13 UTC (permalink / raw)
To: Robin Murphy
Cc: alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH, Christoph Hellwig
On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 04/10/18 00:48, Alexander Duyck wrote:
> > It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
> > <= physiscal memory size") the logic of the test was changed from a "<" to
> > a ">=" however I don't see any reason for that change. I am assuming that
> > there was some additional change planned, specifically I suspect the logic
> > was intended to be reversed and possibly used for a return. Since that is
> > the case I have gone ahead and done that.
>
> Bah, seems I got hung up on the min_mask code above it and totally
> overlooked that the condition itself got flipped. It probably also can't
> help that it's an int return type, but treated as a bool by callers
> rather than "0 for success" as int tends to imply in isolation.
>
> Anyway, paying a bit more attention this time, I think this looks like
> the right fix - cheers Alex.
>
> Robin.
Thanks for the review.
- Alex
P.S. It looks like I forgot to add Christoph to the original mail
since I had just copied the To and Cc from the original submission, so
I added him to the Cc for this.
> > This addresses issues I had on my system that prevented me from booting
> > with the above mentioned commit applied on an x86_64 system w/ Intel IOMMU.
> >
> > Fixes: 9d7a224b463e ("dma-direct: always allow dma mask <= physiscal memory size")
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> > kernel/dma/direct.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 5a0806b5351b..65872f6c2e93 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -301,9 +301,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
> >
> > min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
> >
> > - if (mask >= phys_to_dma(dev, min_mask))
> > - return 0;
> > - return 1;
> > + return mask >= phys_to_dma(dev, min_mask);
> > }
> >
> > int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
> >
> > _______________________________________________
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> >
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-10-04 15:13 ` Alexander Duyck
0 siblings, 0 replies; 17+ messages in thread
From: Alexander Duyck @ 2018-10-04 15:13 UTC (permalink / raw)
To: Robin Murphy
Cc: LKML, open list:INTEL IOMMU (VT-d),
Greg KH, alexander.h.duyck,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Christoph Hellwig, Guenter Roeck
On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 04/10/18 00:48, Alexander Duyck wrote:
> > It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
> > <= physiscal memory size") the logic of the test was changed from a "<" to
> > a ">=" however I don't see any reason for that change. I am assuming that
> > there was some additional change planned, specifically I suspect the logic
> > was intended to be reversed and possibly used for a return. Since that is
> > the case I have gone ahead and done that.
>
> Bah, seems I got hung up on the min_mask code above it and totally
> overlooked that the condition itself got flipped. It probably also can't
> help that it's an int return type, but treated as a bool by callers
> rather than "0 for success" as int tends to imply in isolation.
>
> Anyway, paying a bit more attention this time, I think this looks like
> the right fix - cheers Alex.
>
> Robin.
Thanks for the review.
- Alex
P.S. It looks like I forgot to add Christoph to the original mail
since I had just copied the To and Cc from the original submission, so
I added him to the Cc for this.
> > This addresses issues I had on my system that prevented me from booting
> > with the above mentioned commit applied on an x86_64 system w/ Intel IOMMU.
> >
> > Fixes: 9d7a224b463e ("dma-direct: always allow dma mask <= physiscal memory size")
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> > kernel/dma/direct.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 5a0806b5351b..65872f6c2e93 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -301,9 +301,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
> >
> > min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
> >
> > - if (mask >= phys_to_dma(dev, min_mask))
> > - return 0;
> > - return 1;
> > + return mask >= phys_to_dma(dev, min_mask);
> > }
> >
> > int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
> >
> > _______________________________________________
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> >
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
2018-10-04 15:13 ` Alexander Duyck
(?)
@ 2018-10-05 7:17 ` Christoph Hellwig
-1 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2018-10-05 7:17 UTC (permalink / raw)
To: Alexander Duyck
Cc: Robin Murphy, alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH, Christoph Hellwig
On Thu, Oct 04, 2018 at 08:13:26AM -0700, Alexander Duyck wrote:
> Thanks for the review.
>
> - Alex
>
> P.S. It looks like I forgot to add Christoph to the original mail
> since I had just copied the To and Cc from the original submission, so
> I added him to the Cc for this.
Yes, there was some oddness with replies appearing out of nowhere that
I couldn't understand in my jetlagged state yesterday. Now thay I've
caught up on iommu list traffic it all makes sense now. I've applied
this with an Acked-by for Robin added based on his reply.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-10-05 7:17 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2018-10-05 7:17 UTC (permalink / raw)
To: Alexander Duyck
Cc: Robin Murphy, alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH, Christoph Hellwig
On Thu, Oct 04, 2018 at 08:13:26AM -0700, Alexander Duyck wrote:
> Thanks for the review.
>
> - Alex
>
> P.S. It looks like I forgot to add Christoph to the original mail
> since I had just copied the To and Cc from the original submission, so
> I added him to the Cc for this.
Yes, there was some oddness with replies appearing out of nowhere that
I couldn't understand in my jetlagged state yesterday. Now thay I've
caught up on iommu list traffic it all makes sense now. I've applied
this with an Acked-by for Robin added based on his reply.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-10-05 7:17 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2018-10-05 7:17 UTC (permalink / raw)
To: Alexander Duyck
Cc: Robin Murphy, LKML, open list:INTEL IOMMU (VT-d),
Greg KH, alexander.h.duyck,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Christoph Hellwig, Guenter Roeck
On Thu, Oct 04, 2018 at 08:13:26AM -0700, Alexander Duyck wrote:
> Thanks for the review.
>
> - Alex
>
> P.S. It looks like I forgot to add Christoph to the original mail
> since I had just copied the To and Cc from the original submission, so
> I added him to the Cc for this.
Yes, there was some oddness with replies appearing out of nowhere that
I couldn't understand in my jetlagged state yesterday. Now thay I've
caught up on iommu list traffic it all makes sense now. I've applied
this with an Acked-by for Robin added based on his reply.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
2018-10-04 15:13 ` Alexander Duyck
(?)
@ 2018-12-13 19:45 ` Lendacky, Thomas
-1 siblings, 0 replies; 17+ messages in thread
From: Lendacky, Thomas @ 2018-12-13 19:45 UTC (permalink / raw)
To: Alexander Duyck, Robin Murphy, Christoph Hellwig
Cc: alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH
On 10/04/2018 10:13 AM, Alexander Duyck wrote:
> On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 04/10/18 00:48, Alexander Duyck wrote:
>>> It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
>>> <= physiscal memory size") the logic of the test was changed from a "<" to
>>> a ">=" however I don't see any reason for that change. I am assuming that
>>> there was some additional change planned, specifically I suspect the logic
>>> was intended to be reversed and possibly used for a return. Since that is
>>> the case I have gone ahead and done that.
>>
>> Bah, seems I got hung up on the min_mask code above it and totally
>> overlooked that the condition itself got flipped. It probably also can't
>> help that it's an int return type, but treated as a bool by callers
>> rather than "0 for success" as int tends to imply in isolation.
>>
>> Anyway, paying a bit more attention this time, I think this looks like
>> the right fix - cheers Alex.
>>
>> Robin.
>
> Thanks for the review.
>
> - Alex
>
> P.S. It looks like I forgot to add Christoph to the original mail
> since I had just copied the To and Cc from the original submission, so
> I added him to the Cc for this.
>
>>> This addresses issues I had on my system that prevented me from booting
>>> with the above mentioned commit applied on an x86_64 system w/ Intel IOMMU.
>>>
>>> Fixes: 9d7a224b463e ("dma-direct: always allow dma mask <= physiscal memory size")
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>> kernel/dma/direct.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>>> index 5a0806b5351b..65872f6c2e93 100644
>>> --- a/kernel/dma/direct.c
>>> +++ b/kernel/dma/direct.c
>>> @@ -301,9 +301,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
>>>
>>> min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
>>>
>>> - if (mask >= phys_to_dma(dev, min_mask))
>>> - return 0;
>>> - return 1;
>>> + return mask >= phys_to_dma(dev, min_mask);
So I think this needs to be __phys_to_dma() here. I only recently got a
system that had a device where the driver only supported 32-bit DMA and
found that when SME is active this returns 0 and causes the driver to fail
to initialize. This is because the SME encryption bit (bit 47) is part of
the check when using phys_to_dma(). During actual DMA when SME is active,
bounce buffers will be used for anything that can't meet the 48-bit
requirement. But for this test, using __phys_to_dma() should give the
desired results, right?
If you agree with this, I'll submit a patch to make the change. I missed
this in 4.19, so I'll need to submit something to stable, too. The only
issue there is the 4.20 fix won't apply cleanly to 4.19.
Thanks,
Tom
>>> }
>>>
>>> int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
>>>
>>> _______________________________________________
>>> iommu mailing list
>>> iommu@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>>
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-12-13 19:45 ` Lendacky, Thomas
0 siblings, 0 replies; 17+ messages in thread
From: Lendacky, Thomas @ 2018-12-13 19:45 UTC (permalink / raw)
To: Alexander Duyck, Robin Murphy, Christoph Hellwig
Cc: alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH
On 10/04/2018 10:13 AM, Alexander Duyck wrote:
> On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 04/10/18 00:48, Alexander Duyck wrote:
>>> It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
>>> <= physiscal memory size") the logic of the test was changed from a "<" to
>>> a ">=" however I don't see any reason for that change. I am assuming that
>>> there was some additional change planned, specifically I suspect the logic
>>> was intended to be reversed and possibly used for a return. Since that is
>>> the case I have gone ahead and done that.
>>
>> Bah, seems I got hung up on the min_mask code above it and totally
>> overlooked that the condition itself got flipped. It probably also can't
>> help that it's an int return type, but treated as a bool by callers
>> rather than "0 for success" as int tends to imply in isolation.
>>
>> Anyway, paying a bit more attention this time, I think this looks like
>> the right fix - cheers Alex.
>>
>> Robin.
>
> Thanks for the review.
>
> - Alex
>
> P.S. It looks like I forgot to add Christoph to the original mail
> since I had just copied the To and Cc from the original submission, so
> I added him to the Cc for this.
>
>>> This addresses issues I had on my system that prevented me from booting
>>> with the above mentioned commit applied on an x86_64 system w/ Intel IOMMU.
>>>
>>> Fixes: 9d7a224b463e ("dma-direct: always allow dma mask <= physiscal memory size")
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>> kernel/dma/direct.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>>> index 5a0806b5351b..65872f6c2e93 100644
>>> --- a/kernel/dma/direct.c
>>> +++ b/kernel/dma/direct.c
>>> @@ -301,9 +301,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
>>>
>>> min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
>>>
>>> - if (mask >= phys_to_dma(dev, min_mask))
>>> - return 0;
>>> - return 1;
>>> + return mask >= phys_to_dma(dev, min_mask);
So I think this needs to be __phys_to_dma() here. I only recently got a
system that had a device where the driver only supported 32-bit DMA and
found that when SME is active this returns 0 and causes the driver to fail
to initialize. This is because the SME encryption bit (bit 47) is part of
the check when using phys_to_dma(). During actual DMA when SME is active,
bounce buffers will be used for anything that can't meet the 48-bit
requirement. But for this test, using __phys_to_dma() should give the
desired results, right?
If you agree with this, I'll submit a patch to make the change. I missed
this in 4.19, so I'll need to submit something to stable, too. The only
issue there is the 4.20 fix won't apply cleanly to 4.19.
Thanks,
Tom
>>> }
>>>
>>> int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
>>>
>>> _______________________________________________
>>> iommu mailing list
>>> iommu@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>>
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-12-13 19:45 ` Lendacky, Thomas
0 siblings, 0 replies; 17+ messages in thread
From: Lendacky, Thomas @ 2018-12-13 19:45 UTC (permalink / raw)
To: Alexander Duyck, Robin Murphy, Christoph Hellwig
Cc: LKML, open list:INTEL IOMMU (VT-d),
Greg KH, alexander.h.duyck,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Guenter Roeck
On 10/04/2018 10:13 AM, Alexander Duyck wrote:
> On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 04/10/18 00:48, Alexander Duyck wrote:
>>> It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
>>> <= physiscal memory size") the logic of the test was changed from a "<" to
>>> a ">=" however I don't see any reason for that change. I am assuming that
>>> there was some additional change planned, specifically I suspect the logic
>>> was intended to be reversed and possibly used for a return. Since that is
>>> the case I have gone ahead and done that.
>>
>> Bah, seems I got hung up on the min_mask code above it and totally
>> overlooked that the condition itself got flipped. It probably also can't
>> help that it's an int return type, but treated as a bool by callers
>> rather than "0 for success" as int tends to imply in isolation.
>>
>> Anyway, paying a bit more attention this time, I think this looks like
>> the right fix - cheers Alex.
>>
>> Robin.
>
> Thanks for the review.
>
> - Alex
>
> P.S. It looks like I forgot to add Christoph to the original mail
> since I had just copied the To and Cc from the original submission, so
> I added him to the Cc for this.
>
>>> This addresses issues I had on my system that prevented me from booting
>>> with the above mentioned commit applied on an x86_64 system w/ Intel IOMMU.
>>>
>>> Fixes: 9d7a224b463e ("dma-direct: always allow dma mask <= physiscal memory size")
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>> kernel/dma/direct.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>>> index 5a0806b5351b..65872f6c2e93 100644
>>> --- a/kernel/dma/direct.c
>>> +++ b/kernel/dma/direct.c
>>> @@ -301,9 +301,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
>>>
>>> min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
>>>
>>> - if (mask >= phys_to_dma(dev, min_mask))
>>> - return 0;
>>> - return 1;
>>> + return mask >= phys_to_dma(dev, min_mask);
So I think this needs to be __phys_to_dma() here. I only recently got a
system that had a device where the driver only supported 32-bit DMA and
found that when SME is active this returns 0 and causes the driver to fail
to initialize. This is because the SME encryption bit (bit 47) is part of
the check when using phys_to_dma(). During actual DMA when SME is active,
bounce buffers will be used for anything that can't meet the 48-bit
requirement. But for this test, using __phys_to_dma() should give the
desired results, right?
If you agree with this, I'll submit a patch to make the change. I missed
this in 4.19, so I'll need to submit something to stable, too. The only
issue there is the 4.20 fix won't apply cleanly to 4.19.
Thanks,
Tom
>>> }
>>>
>>> int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
>>>
>>> _______________________________________________
>>> iommu mailing list
>>> iommu@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>>
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
2018-12-13 19:45 ` Lendacky, Thomas
(?)
@ 2018-12-13 19:58 ` Christoph Hellwig
-1 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2018-12-13 19:58 UTC (permalink / raw)
To: Lendacky, Thomas
Cc: Alexander Duyck, Robin Murphy, Christoph Hellwig,
alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH
On Thu, Dec 13, 2018 at 07:45:57PM +0000, Lendacky, Thomas wrote:
> So I think this needs to be __phys_to_dma() here. I only recently got a
> system that had a device where the driver only supported 32-bit DMA and
> found that when SME is active this returns 0 and causes the driver to fail
> to initialize. This is because the SME encryption bit (bit 47) is part of
> the check when using phys_to_dma(). During actual DMA when SME is active,
> bounce buffers will be used for anything that can't meet the 48-bit
> requirement. But for this test, using __phys_to_dma() should give the
> desired results, right?
>
> If you agree with this, I'll submit a patch to make the change. I missed
> this in 4.19, so I'll need to submit something to stable, too. The only
> issue there is the 4.20 fix won't apply cleanly to 4.19.
Yes, please send a patch. Please make sure it includes a code comment
that explains why the __-prefixed version is used.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-12-13 19:58 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2018-12-13 19:58 UTC (permalink / raw)
To: Lendacky, Thomas
Cc: Alexander Duyck, Robin Murphy, Christoph Hellwig,
alexander.h.duyck, open list:INTEL IOMMU (VT-d),
Benjamin Herrenschmidt,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
LKML, Guenter Roeck, Greg KH
On Thu, Dec 13, 2018 at 07:45:57PM +0000, Lendacky, Thomas wrote:
> So I think this needs to be __phys_to_dma() here. I only recently got a
> system that had a device where the driver only supported 32-bit DMA and
> found that when SME is active this returns 0 and causes the driver to fail
> to initialize. This is because the SME encryption bit (bit 47) is part of
> the check when using phys_to_dma(). During actual DMA when SME is active,
> bounce buffers will be used for anything that can't meet the 48-bit
> requirement. But for this test, using __phys_to_dma() should give the
> desired results, right?
>
> If you agree with this, I'll submit a patch to make the change. I missed
> this in 4.19, so I'll need to submit something to stable, too. The only
> issue there is the 4.20 fix won't apply cleanly to 4.19.
Yes, please send a patch. Please make sure it includes a code comment
that explains why the __-prefixed version is used.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] dma-direct: Fix return value of dma_direct_supported
@ 2018-12-13 19:58 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2018-12-13 19:58 UTC (permalink / raw)
To: Lendacky, Thomas
Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Alexander Duyck, LKML, open list:INTEL IOMMU (VT-d),
Greg KH, alexander.h.duyck, Robin Murphy, Christoph Hellwig,
Guenter Roeck
On Thu, Dec 13, 2018 at 07:45:57PM +0000, Lendacky, Thomas wrote:
> So I think this needs to be __phys_to_dma() here. I only recently got a
> system that had a device where the driver only supported 32-bit DMA and
> found that when SME is active this returns 0 and causes the driver to fail
> to initialize. This is because the SME encryption bit (bit 47) is part of
> the check when using phys_to_dma(). During actual DMA when SME is active,
> bounce buffers will be used for anything that can't meet the 48-bit
> requirement. But for this test, using __phys_to_dma() should give the
> desired results, right?
>
> If you agree with this, I'll submit a patch to make the change. I missed
> this in 4.19, so I'll need to submit something to stable, too. The only
> issue there is the 4.20 fix won't apply cleanly to 4.19.
Yes, please send a patch. Please make sure it includes a code comment
that explains why the __-prefixed version is used.
^ permalink raw reply [flat|nested] 17+ messages in thread