On Wed, Oct 11, 2017 at 12:36:11PM +, Horia Geantă wrote:
> Hi Herbert,
>
> I am evaluating whether ahash implementation in caam crypto driver
> behaves correctly.
> One thing I've noticed is that for each ahash tfm there is support for
> at most two in-flight requests, and I would like to kno
On 10/10/17 22:28, Jonathan Cameron wrote:
Hi All,
Please forward this email to anyone you think may be interested.
Have forwarded this to a number of relevant IBMers.
On behalf of Huawei, I am looking into options to foster a wider community
around the various ongoing projects related to Ac
On Wed, Oct 11, 2017 at 03:45:00PM -0500, Brijesh Singh wrote:
> OK, if userspace is going to pick bits apart then how about this:
>
> struct sev_data_status {
> u8 api_major; /* Out */
> u8 api_minor; /* Out */
> u8 s
On 10/11/2017 03:45 PM, Brijesh Singh wrote:
On 10/11/2017 03:28 PM, Borislav Petkov wrote:
On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote:
The current 'struct sev_data_status' matches with the firmware names
and the
bit fields. Only thing I did was the fields with no name i
On 10/11/2017 03:28 PM, Borislav Petkov wrote:
On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote:
The current 'struct sev_data_status' matches with the firmware names and the
bit fields. Only thing I did was the fields with no name is called as
"reservedX"
Ok, I see it. So what y
On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote:
> The current 'struct sev_data_status' matches with the firmware names and the
> bit fields. Only thing I did was the fields with no name is called as
> "reservedX"
Ok, I see it. So what you actually wanna do is:
struct sev_data_statu
On Wed, Oct 11, 2017 at 10:04:44PM +0200, Borislav Petkov wrote:
> Then it is easy:
>
>&= GENMASK(23, 1);
[1:23] range cleared, of course:
&= ~GENMASK(23, 1);
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nür
On 10/11/2017 03:04 PM, Borislav Petkov wrote:
On Wed, Oct 11, 2017 at 02:49:55PM -0500, Brijesh Singh wrote:
This is OK for now. But in future if FW steals another bit from reserved1
field to expose a new flag then 'owner' name will no longer be valid. If you
don't to use bit field then we ha
On Wed, Oct 11, 2017 at 02:49:55PM -0500, Brijesh Singh wrote:
> This is OK for now. But in future if FW steals another bit from reserved1
> field to expose a new flag then 'owner' name will no longer be valid. If you
> don't to use bit field then we have to use some generic name instead of
> namin
On 10/11/2017 12:02 PM, Borislav Petkov wrote:
...
What's with the curly brackets around the case: statements?
I will remove the curly braces.
Anyway, here are some more improvements:
* you can get rid of the struct copying into out and the bitfields by
doing something like this:
On Fri, Oct 06, 2017 at 08:06:02PM -0500, Brijesh Singh wrote:
> The SEV_PLATFORM_STATUS command can be used by the platform owner to
> get the current status of the platform. The command is defined in
> SEV spec section 5.5.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Borislav Petkov
> Cc
The SEV_PLATFORM_STATUS command can be used by the platform owner to
get the current status of the platform. The command is defined in
SEV spec section 5.5.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
The SEV_FACTORY_RESET command can be used by the platform owner to
reset the non-volatile SEV related data. The command is defined in
SEV spec section 5.4
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
C
On Wed, 11 Oct 2017 11:51:49 -0400
Sandy Harris wrote:
> I shortened the cc list radically. If the discussion continues, it may
> be a good idea to add people back. I added John Gilmore since I cite
> one of his posts below.
Fair enough - I have cc'd back in our internal list for now.
I cynicall
AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP) which exposes the
commands for the
Add a include file which defines the ioctl and command id used for
issuing SEV platform management specific commands.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: linux-ker
I shortened the cc list radically. If the discussion continues, it may
be a good idea to add people back. I added John Gilmore since I cite
one of his posts below.
Jonathan Cameron wrote:
> On behalf of Huawei, I am looking into options to foster a wider community
> around the various ongoing pr
On Tue, 10 Oct 2017 16:55:06 +0200
Francois Ozog wrote:
> Hi,
Hi Francois,
Firstly, to anyone seeing this on the mailing lists, there was an attachment so
it presumably bounced.
>
> I am really happy you started this thread. I think we need to have Grant
> Likely from Arm involved in the topic
On Fri, Oct 06, 2017 at 08:06:01PM -0500, Brijesh Singh wrote:
> The SEV_FACTORY_RESET command can be used by the platform owner to
> reset the non-volatile SEV related data. The command is defined in
> SEV spec section 5.4
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Borislav Petkov
> Cc:
On 10/11/2017 09:19 AM, Borislav Petkov wrote:
On Sun, Oct 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote:
Basically we need some variable which is outside the per-device
structure so that we don't end up creating multiple /dev/sev nodes. If
needed, I think we can remove 'has_sev_fops' vari
On Sun, Oct 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote:
> Basically we need some variable which is outside the per-device
> structure so that we don't end up creating multiple /dev/sev nodes. If
> needed, I think we can remove 'has_sev_fops' variable from struct
> psp_device if we decide to
Hey Boris,
On Wed, Oct 11, 2017 at 03:16:16PM +0200, Boris Brezillon wrote:
> Hello,
>
> It's been several releases since we added a new driver to support the
> CESA IP (the new driver was introduced in 4.2). It seems most major
> bugs have been discovered and fixed and now is probably a good tim
All defconfigs selecting the old driver have been patched to select
the new one instead. We can now remove the old driver along with the
allhwsupports module parameter in the new driver that was used to
check whether the new driver was allowed to take control of the CESA
engine or not.
Signed-off-
Hello,
It's been several releases since we added a new driver to support the
CESA IP (the new driver was introduced in 4.2). It seems most major
bugs have been discovered and fixed and now is probably a good time to
kill the old driver and force remaining users to switch to the new one.
This seri
Add a platform_device_id table to allow using this driver on orion
platforms that have not been converted to DT.
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.
A new driver has been developed to support the CESA IP. Switch
remaining users of the old driver to the new driver in order to remove
the old one.
Signed-off-by: Boris Brezillon
---
arch/arm/configs/dove_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/orion5x_d
Hi Herbert,
I am evaluating whether ahash implementation in caam crypto driver
behaves correctly.
One thing I've noticed is that for each ahash tfm there is support for
at most two in-flight requests, and I would like to know whether this is
an issue or not.
In this context, could you please clar
27 matches
Mail list logo
