From: Yoan Picchi <yoan.picchi@foss.arm.com>
To: ardb@kernel.org
Cc: andre.przywara@arm.com, davem@davemloft.net,
giovanni.cabiddu@intel.com, herbert@gondor.apana.org.au,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
qat-linux@intel.com, yoan.picchi@arm.com
Subject: Re: [RFC PATCH 2/2] Removes the x86 dependency on the QAT drivers
Date: Mon, 30 May 2022 10:58:13 +0100 [thread overview]
Message-ID: <49eb2888-712e-7c81-313b-aec58e906778@foss.arm.com> (raw)
In-Reply-To: <CAMj1kXEF6KV=3CXhaRKygBs9hvun7=bKRua5NbWOrksaZBgtCQ@mail.gmail.com>
> On Wed, 18 May 2022 at 17:55, Andre Przywara <andre.przywara@arm.com>
wrote:
> >
> > On Tue, 17 May 2022 10:11:09 +0200
> > Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > Hi,
> >
> > > On Mon, 16 May 2022 at 12:16, <yoan.picchi@arm.com> wrote:
> > > >
> > > > From: Yoan Picchi <yoan.picchi@arm.com>
> > > >
> > > > This dependency looks outdated. After the previous patch, we
have been able
> > > > to use this driver to encrypt some data and to create working
VF on arm64.
> > > >
> > > > Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
> > >
> > > Are you sure the driver is safe for non-coherent DMA as well?
> >
> > That depends on your definition of "sure".
> > We indeed tested this only on a server with coherent PCIe.
> >
> > I skimmed through the driver, and it looks like to use the DMA API
> > correctly:
> > - I see dma_alloc_coherent() calls for DMA ring buffers.
> > - There are dma_map_single()/dma_unmap_single() pairs in other parts.
> > - Accesses to the BARs are capsuled via macros, using readl/writel.
> > - Access the the SRAM BAR is also only done via those macros.
> >
> > I didn't go through the driver systematically, and of course the
> > interesting parts are the ones you don't see easily, so I am eager
to hear
> > any other opinions on this topic.
> >
> > Ard, do you have anything special in mind? Is there something to
look out
> > for, specifically?
> >
>
> If it uses the DMA api consistently and correctly, and works as
> expected when running under a SMMU, things are probably fine
>
> > The few cards we have access to are in some server in the data
centre, so
> > I can't easily walk in with, say a RockPro64, and test this there.
> >
>
> I suppose this implies that you have tested with SMMUs enabled.
Sorry for the delay, I was away for a few days.
Actually, our previous attempts were with the iommu set to passthrough,
but I
just tested without the passthrough and it works the same way.
>
> > >
> > > > ---
> > > > drivers/crypto/qat/Kconfig | 14 +++++++-------
> > > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/crypto/qat/Kconfig
b/drivers/crypto/qat/Kconfig
> > > > index 4b90c0f22b03..88df2cf4cac9 100644
> > > > --- a/drivers/crypto/qat/Kconfig
> > > > +++ b/drivers/crypto/qat/Kconfig
> > > > @@ -17,7 +17,7 @@ config CRYPTO_DEV_QAT
> > > >
> > > > config CRYPTO_DEV_QAT_DH895xCC
> > > > tristate "Support for Intel(R) DH895xCC"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select CRYPTO_DEV_QAT
> > > > help
> > > > Support for Intel(R) DH895xcc with Intel(R)
QuickAssist Technology
> > > > @@ -28,7 +28,7 @@ config CRYPTO_DEV_QAT_DH895xCC
> > > >
> > > > config CRYPTO_DEV_QAT_C3XXX
> > > > tristate "Support for Intel(R) C3XXX"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select CRYPTO_DEV_QAT
> > > > help
> > > > Support for Intel(R) C3xxx with Intel(R) QuickAssist
Technology
> > > > @@ -39,7 +39,7 @@ config CRYPTO_DEV_QAT_C3XXX
> > > >
> > > > config CRYPTO_DEV_QAT_C62X
> > > > tristate "Support for Intel(R) C62X"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select CRYPTO_DEV_QAT
> > > > help
> > > > Support for Intel(R) C62x with Intel(R) QuickAssist
Technology
> > > > @@ -50,7 +50,7 @@ config CRYPTO_DEV_QAT_C62X
> > > >
> > > > config CRYPTO_DEV_QAT_4XXX
> > > > tristate "Support for Intel(R) QAT_4XXX"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select CRYPTO_DEV_QAT
> > > > help
> > > > Support for Intel(R) QuickAssist Technology QAT_4xxx
> > > > @@ -61,7 +61,7 @@ config CRYPTO_DEV_QAT_4XXX
> > > >
> > > > config CRYPTO_DEV_QAT_DH895xCCVF
> > > > tristate "Support for Intel(R) DH895xCC Virtual Function"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select PCI_IOV
> > > > select CRYPTO_DEV_QAT
> > > >
> > > > @@ -74,7 +74,7 @@ config CRYPTO_DEV_QAT_DH895xCCVF
> > > >
> > > > config CRYPTO_DEV_QAT_C3XXXVF
> > > > tristate "Support for Intel(R) C3XXX Virtual Function"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select PCI_IOV
> > > > select CRYPTO_DEV_QAT
> > > > help
> > > > @@ -86,7 +86,7 @@ config CRYPTO_DEV_QAT_C3XXXVF
> > > >
> > > > config CRYPTO_DEV_QAT_C62XVF
> > > > tristate "Support for Intel(R) C62X Virtual Function"
> > > > - depends on X86 && PCI
> > > > + depends on PCI
> > > > select PCI_IOV
> > > > select CRYPTO_DEV_QAT
> > > > help
> > > > --
> > > > 2.25.1
> > > >
> >
next prev parent reply other threads:[~2022-05-30 9:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 10:16 [RFC PATCH 0/2] Crypto: Remove x86 dependency on QAT drivers yoan.picchi
2022-05-16 10:16 ` [RFC PATCH 1/2] crypto: qat: replace get_current_node() with numa_node_id() yoan.picchi
2022-05-16 10:16 ` [RFC PATCH 2/2] Removes the x86 dependency on the QAT drivers yoan.picchi
2022-05-17 8:11 ` Ard Biesheuvel
2022-05-18 13:00 ` Yoan Picchi
2022-05-24 7:51 ` Giovanni Cabiddu
2022-05-25 13:12 ` Andre Przywara
2022-05-27 8:45 ` Giovanni Cabiddu
2022-05-18 15:55 ` Andre Przywara
2022-05-24 8:04 ` Ard Biesheuvel
2022-05-30 9:58 ` Yoan Picchi [this message]
2022-05-30 10:09 ` Ard Biesheuvel
2022-05-16 20:25 ` [RFC PATCH 0/2] Crypto: Remove x86 dependency on " Giovanni Cabiddu
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=49eb2888-712e-7c81-313b-aec58e906778@foss.arm.com \
--to=yoan.picchi@foss.arm.com \
--cc=andre.przywara@arm.com \
--cc=ardb@kernel.org \
--cc=davem@davemloft.net \
--cc=giovanni.cabiddu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qat-linux@intel.com \
--cc=yoan.picchi@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox