On 22 June 2018 at 11:37, Hongbo Zhang <[email protected]> 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 <[email protected]> > --- > 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
