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

[Hongbo Zhang]

On 25 June 2018 at 17:06, Peter Maydell <address@hidden> wrote:
> On 25 June 2018 at 05:06, Hongbo Zhang <address@hidden> wrote:
>> 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.
>
> I'm afraid I don't really understand what you're saying
> here. Could you try rephrasing it?
>
Sorry, I say in the real hardware platforms, in practice programmer
has to write a fixed PSCI conduit value in ACPI. then on the qemu
platform, I did the similar thing -- write a fixed value too.
I know it is not a perfect solution for it, I have no better one for now.

> If we're running at EL3 and booting firmware, then QEMU doesn't
> provide PSCI. The firmware we're booting is the only thing that
> can know if that firmware has implemented PSCI. So only it can
> decide whether the ACPI tables and DTB should say that PSCI is
> present.

Agree with your comments, I hope ACPI's psci conduit node can reflect
firmware's implementation, even when firmware PSCI conduit changes,
ACPI node changes accordingly.
But for ACPI and DTB, there are different situations now.

If DTB is used, firmware(with psci implementation) can generate DTB
nodes, saying which PSCI conduit is used - smc or hvc, then uboot or
uefi can get this DTB add more DTB nodes before transfer it to kernel.
That is, using DTB, we can achieve the goal.

But when ACPI used, there is no codes in firmware to generate ACPI
node to show which PSCI conduit is used, then uefi or later stage
cannot get this info dynamically from any codes as far as I know.
(this is why programmer manually check that firmware is using smc,
then write a fixed value in ACPI FADT).
So, if we want to fix this neatly, adding ACPI support in Arm trusted
firmware may be the solution, but it should be a big feature for
firmware, not QEMU.

(since many components involved, hope my understanding correct)
>
> thanks
> -- PMM