Re: [edk2-devel] [PATCH 2/3] ArmVirtPkg/ArmVirtQemu: Expose TRNG hypercall via RngDxe if implemented

["Ard Biesheuvel" <ardb@kernel.org>]

On Wed, 11 Jan 2023 at 18:38, PierreGondois <pierre.gondois@arm.com> wrote:
>
>
>
> On 1/11/23 17:49, Ard Biesheuvel wrote:
> > On Fri, 18 Nov 2022 at 17:48, PierreGondois <pierre.gondois@arm.com> 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 <ardb@kernel.org>
> >>> ---
> >>>    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
>

Hmm, that is a fair point.

I wonder if we should simply detect whether we are executing at EL1 or
EL2, and use HVC or SVC respectively.


> >
> > 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
> >>
> >>
> >>
> >>
> >>
>
>
> 
>
>