From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1910B1758F; Sat, 31 Aug 2024 07:42:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725090147; cv=none; b=jZs77cPeWdQFcMDkPnVVnrqoqowBcVrqAIpJekczOYA9hP3PKQIZY8971Xcr0SR4GmzwgEaMa0oo5P0/HGx/HrzAgtLS+zwAr+nBogWzLbdwChO0tPUeoPZy2qPpHt2vUapLiB6p+FvikoWidIxR7FOvjblsBs0CXiLvHouz6fs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725090147; c=relaxed/simple; bh=CSYles6ImJnP6hRgL02AQveRmBHZZvF8jl7dwBIrqss=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=YknfcB4bq1KTa9maYdhuXr6sdyFGWEM8RW/LFkQloK5EeGLz2fAeh1N9CPplLJsufgux043NruIp7llx/6/qTiNWLjPEeVlYwvprJUpF5qfcXqwAm1C0eETu38wMVF1sRCHAZVtQWPhJ0gWDGgY3GjGALUAcz3w6JFnwB4J7E3k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tn0HWQeu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tn0HWQeu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 924FDC4CEC0; Sat, 31 Aug 2024 07:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725090146; bh=CSYles6ImJnP6hRgL02AQveRmBHZZvF8jl7dwBIrqss=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tn0HWQeuZfUPF/N6YWMS4/kIkP/e80G4QduNmZ186OA2/aDlwmBaNQ5jPMh3h5MXV 8PqZdrQdMSAWU0TUxH1kAhPPckZyXnTDRBqHNndHMOoZ+gsrqWswRH4ZA0WvpqohFr 3VH1Ljj2nqhiZgBh+kIr4vmILJ763GWrG5zCPUcEkxdvMeRkpXCZAJgxfdLhpYVmK4 /p9WGi3pIQPYbKN0ghTwVOpxUkkDe/RPZMkSTcxsfpcSblT56zn0Kf09Zy1KJICtpC zHHCsJJbHaQzUdRxb0cUGF+c9csvH+TnmNwe0PvUptstp9Ukf4g7P6+yEeguh/2r0g LJB3+stHfRLXw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1skIka-008RVF-7l; Sat, 31 Aug 2024 08:42:24 +0100 Date: Sat, 31 Aug 2024 08:42:23 +0100 Message-ID: <86zfotuoio.wl-maz@kernel.org> From: Marc Zyngier To: Tangnianyao Cc: Will Deacon , , , , , "guoyang (C)" , Ard Biesheuvel Subject: Re: Question on get random long worse in VM than on host In-Reply-To: <214e37e9-7aba-1e61-f63f-85cb10c9a878@huawei.com> References: <214e37e9-7aba-1e61-f63f-85cb10c9a878@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tangnianyao@huawei.com, will@kernel.org, oliver.upton@linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, guoyang2@huawei.com, ardb@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false [+ Ard, who actually understands the whole RNG thing] On Sat, 31 Aug 2024 04:34:33 +0100, Tangnianyao wrote: > > Hi, all > > On ARM64 server(Kunpeng), performance of some syscall cases (like fork > and open) in guest, which need random u64, are 10~20% worse than > those on host. Because CONFIG_ARCH_HAS_ELF_RANDOMIZE=y and > CONFIG_STACKPROTECTOR=y, guest kernel need random u64 and > require them from host kvm using hvc. > > If FEAT_RNG is supported and EL3 firmware not support smccc trng, host > kvm finally return random u64 using RNDRRS to guest. > > Shall we firstly let guest get random u64 from RNDRRS to avoid hvc trap? > For example, if host find smccc trng not available, then tell guest smccc > trng not available when guest check trng version. My recollection is that it was a deliberate decision to decouple what the host firmware offers from what the guest sees (we can always implement the SMCCC TRNG using any mechanism that the host has to deliver entropy). Now, userspace has almost complete freedom to expose what the guest sees in terms of PV services. In this particular case, it can write to the KVM_REG_ARM_STD_BMAP pseudo register to remove the KVM_REG_ARM_STD_BIT_TRNG_V1_0 bit from the bitmap, which will hide the functionality. Isn't this sufficient here? Given that you seem to be micro-optimising for a particular platform, this seems like the easiest way to reach your goal without having to change anything. Thanks, M. -- Without deviation from the norm, progress is not possible.