From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web11.30829.1673458724943482143 for ; Wed, 11 Jan 2023 09:38:45 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: pierre.gondois@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 17DBDFEC; Wed, 11 Jan 2023 09:39:26 -0800 (PST) Received: from [10.57.90.112] (unknown [10.57.90.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F5C43F587; Wed, 11 Jan 2023 09:38:42 -0800 (PST) Message-ID: Date: Wed, 11 Jan 2023 18:38:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [edk2-devel] [PATCH 2/3] ArmVirtPkg/ArmVirtQemu: Expose TRNG hypercall via RngDxe if implemented To: Ard Biesheuvel , devel@edk2.groups.io Cc: Liming Gao , Rebecca Cran , Leif Lindholm , Sami Mujawar , Gerd Hoffmann , "Jason A . Donenfeld" References: <20221110134738.3798618-1-ardb@kernel.org> <20221110134738.3798618-3-ardb@kernel.org> From: "PierreGondois" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/11/23 17:49, Ard Biesheuvel wrote: > On Fri, 18 Nov 2022 at 17:48, PierreGondois wrote: >> >> Hello Ard, >> >> On 11/10/22 14:47, Ard Biesheuvel wrote: >>> Currently, we only expose the EFI_RNG_PROTOCOL in ArmVirtQemu if QEMU >>> provides a virtio-rng device, and it doesn't do so by default. >>> >>> Given that KVM exposes the ARM architected TRNG service (and has done so >>> for a while now), let's incorporate the RngDxe driver which has recently >>> grown support for the ARM firmware/hypervisor service. >>> >>> If both the service and the virtio device are available, two >>> implementations of the RNG protocol will be exposed, but this is fine: >>> callers that don't care about the distinction will grab the first one >>> available. >>> >>> Signed-off-by: Ard Biesheuvel >>> --- >>> ArmVirtPkg/ArmVirtQemu.dsc | 11 +++++++++++ >>> ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 5 +++++ >>> ArmVirtPkg/ArmVirtQemuKernel.dsc | 11 +++++++++++ >>> 3 files changed, 27 insertions(+) >>> >>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc >>> index f77443229e8e..1771ad562225 100644 >>> --- a/ArmVirtPkg/ArmVirtQemu.dsc >>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc >>> @@ -140,6 +140,8 @@ [PcdsFeatureFlag.common] >>> >>> gArmVirtTokenSpaceGuid.PcdTpm2SupportEnabled|$(TPM2_ENABLE) >>> >>> + gArmTokenSpaceGuid.PcdMonitorConduitHvc|TRUE >>> + >> >> It seems that the PSCI conduit needs to be dynamically set. > > Why? And how is this different from PSCI for resetting the system? The PSCI implementation used for ArmVirtQemu is parsing the conduit to use, so it can handle both cases: https://github.com/tianocore/edk2/blob/fe405f08a09e9f2306c72aa23d8edfbcfaa23bff/ArmVirtPkg/Library/ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.c#L49 > > Note that ArmVIrtQemu was never intended to run at EL2, even if it > seems to work to some extent. Ok understood. > > >> The psci conduit that should be used is configured by qemu depending on the >> virtualization=[on|off] parameter. When off, HVC must be used (SMC otherwise). >> Cf: >> https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L2052 (replacing with a permanent link) https://github.com/qemu/qemu/blob/aa96ab7c9df59c615ca82b49c9062819e0a1c287/hw/arm/virt.c#L2080 >> >> If using the wrong conduit, qemu traps the instruction and stops. >> For KvmTool, the conduit is always HVC. >> >> Command used: >> [PATH_TO]/qemu/build/qemu-system-aarch64 \ >> -serial stdio -M virt,highmem=on,virtualization=off \ >> -cpu cortex-a57 -smp 4 -m 4096 \ >> -drive file=pflash0.img,format=raw,if=pflash,readonly=on \ >> -drive file=pflash1.img,format=raw,if=pflash >> >> Regards, >> Pierre >> >> >> >> >>