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

[Peter Maydell]

On 25 June 2018 at 10:56, Hongbo Zhang <address@hidden> wrote:
> 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.

I think my view here remains the same. QEMU does not and cannot
know what the EL3 firmware is providing for a PSCI conduit. So
it can't put anything in the ACPI table fragments. It has to be
up to the guest code at EL3 to determine the right answer and
put it in the ACPI table or DT that gets used at EL1 or EL2.

thanks
-- PMM