From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FC18C47082 for ; Wed, 26 May 2021 23:57:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 545006108B for ; Wed, 26 May 2021 23:57:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 545006108B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Date:Cc:To:From:Subject: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=yzDEXmNiabg7SaKFNz6AI5XR2QjiF7UlcYw/LnkLaFQ=; b=jYZZTShByJW+Ix ZWGfqKpUxWjzylhommrQix8hxXkGLMzeUMNrV/hKWyo8ToKzMs7rF/EkQSCm8BNYdYfud0/lZT4er BSyU5BiYZEGU/zewCnRKHiA1ic5w3G0CCo5Fr69/bTRFpLn7RXgW6GDcyapg44nPqnAr0zGMCtTiL HYJzX8C6ZfNhnZk6Q+ygypcmZTV/BtTUVPaRBE8jNPhNUgGAwPnKgMkGgw2xMfP1xA3nUXlf3PYfF na0P6bosc8E2ec1yyriq7A3DrYDVbT12o1B0qWOIki4fJaJLRrvR7ceOTe1e2KwoMQoNSBvyNNIWJ aK+j6HV6BZVnoHllhauA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lm3Mt-00103p-No; Wed, 26 May 2021 23:55:19 +0000 Received: from gate.crashing.org ([63.228.1.57]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lm3Mq-00101x-8o for linux-arm-kernel@lists.infradead.org; Wed, 26 May 2021 23:55:17 +0000 Received: from ip6-localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 14QNs33h003977; Wed, 26 May 2021 18:54:04 -0500 Message-ID: <7d5697f3994fc1f9cf39d332525269056e3649b3.camel@kernel.crashing.org> Subject: RNDR/SS vs. SMCCC From: Benjamin Herrenschmidt To: Andre Przywara Cc: Mark Brown , Will Deacon , "Saidi, Ali" , benh@amazon.com, linux-arm-kernel@lists.infradead.org Date: Thu, 27 May 2021 09:54:03 +1000 User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210526_165516_621316_E7FB7E96 X-CRM114-Status: UNSURE ( 7.14 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi folks ! I'm trying to understand the rationale for having SMCCC take precedence over the architected instruction in arch/arm64/include/asm/archrandom.h Especially I don't quite get the comment about SMCCC being more in the "spirit" than let's say RNDRSS. It's definitely MUCH slower. Also, why not implement arch_get_random_* using RNDR rather than forcing these through the kernel CNRG ? Finally, RNDR/RNDRSS can fail occasionally, we should probably implement some kind of delay+retry here. I'm not super familiar with the context in which arch_get_random_* can be called (are they allowed to sleep ?) but from the implementation I'm aware of at least, the idea is that they might under some HW recovery scenarii so we should sleep a couple of ms and try again a few times. Thoughts ? Cheers, Ben. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel