Re: [Qemu-arm] [PATCH] hw/arm/virt: fix psci conduit in acpi when el3 enabled

[Peter Maydell]

On 22 June 2018 at 11:37, Hongbo Zhang <address@hidden> wrote:
> When QEMU_PSCI_CONDUIT_DISABLED is set, it doesn't mean all the PSCI
> conduits are totally disabled, it only mean the QEMU built-in PSCI
> support is disabled, in such a case, e.g. EL3 is enabled and external
> firmware (it is usually Arm Trusted Firmware) is loaded, SMC should be
> used for the guest to trigger PSCI functions.
>
> Signed-off-by: Hongbo Zhang <address@hidden>
> ---
>  hw/arm/virt-acpi-build.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 74f5744..e5b4947 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -715,7 +715,11 @@ static void build_fadt_rev5(GArray *table_data, 
> BIOSLinker *linker,
>
>      switch (vms->psci_conduit) {
>      case QEMU_PSCI_CONDUIT_DISABLED:
> -        fadt.arm_boot_arch = 0;
> +        /* This case means QEMU's internal EL3 implementation is disabled,
> +         * but when firmware is loaded, the guest can still use SMC as PSCI
> +         * conduit to call external firmware PSCI services
> +         */
> +        fadt.arm_boot_arch = ACPI_FADT_ARM_PSCI_COMPLIANT;
>          break;
>      case QEMU_PSCI_CONDUIT_HVC:
>          fadt.arm_boot_arch = ACPI_FADT_ARM_PSCI_COMPLIANT |

I think this means we end up reporting different things for ACPI
and DT in this case, doesn't it?

I think that if QEMU isn't providing the PSCI implementation it
shouldn't advertise it in the ACPI tables. It would seem more
logical that the firmware itself does that (QEMU can't know if
it really does provide PSCI, after all...)

thanks
-- PMM