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

[Hongbo Zhang]

Hi Peter,
Yes, your considerations reasonable.
But in practice of hardware platforms, programmer checks that Arm TF
is using SMC for PSCI call conduit, then fix it manually in the ACPI
table, reason may be that Arm TF is lack of ACPI support, if device
tree used, there should be no such thing because Arm TF can support
it.
On QEMU, I just mimic the situation, if a complete reasonable
solution, further efforts are needed to figure it out.

On 22 June 2018 at 18:45, Peter Maydell <address@hidden> wrote:
> 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