On 13.09.21 10:54, Peter Maydell wrote: > On Mon, 13 Sept 2021 at 00:08, Alexander Graf <ag...@csgraf.de> wrote: >> We need to handle PSCI calls. Most of the TCG code works for us, >> but we can simplify it to only handle aa64 mode and we need to >> handle SUSPEND differently. >> >> This patch takes the TCG code as template and duplicates it in HVF. >> >> To tell the guest that we support PSCI 0.2 now, update the check in >> arm_cpu_initfn() as well. >> >> Signed-off-by: Alexander Graf <ag...@csgraf.de> >> Reviewed-by: Sergio Lopez <s...@redhat.com> >> >> --- >> >> v6 -> v7: >> >> - This patch integrates "arm: Set PSCI to 0.2 for HVF" >> >> v7 -> v8: >> >> - Do not advance for HVC, PC is already updated by hvf >> - Fix checkpatch error >> >> v8 -> v9: >> >> - Use new hvf_raise_exception() prototype >> - Make cpu_off function void >> - Add comment about return value, use -1 for "not found" >> - Remove cpu_synchronize_state() when halted >> --- >> target/arm/cpu.c | 4 +- >> target/arm/hvf/hvf.c | 127 ++++++++++++++++++++++++++++++++++-- >> target/arm/hvf/trace-events | 1 + >> 3 files changed, 126 insertions(+), 6 deletions(-) > Something in here should be checking whether the insn the guest > used matches the PSCI conduit configured for the VM, ie > what arm_is_psci_call() does after your patch 10.
It's yet another case where I believe we are both reading the spec differently :) https://documentation-service.arm.com/static/6013e5faeee5236980d08619 Section 2.5.3 speaks about the conduits. It says Service calls are expected to be invoked through SMC instructions, except for Standard Hypervisor Calls and Vendor Specific Hypervisor Calls. On some platforms, however, SMC instructions are not available, and the services can be accessed through HVC instructions. The method that is used to invoke the service is referred to as the conduit. To me, that reads like "Use SMC whenever you can. If your hardware does not give you a way to handle SMC calls, falling back to HVC is ok. In that case, indicate that mandate to the OS". In hvf, we can very easily trap for SMC calls and handle them. Why are we making OSs implement HVC call paths when SMC would work just as well for everyone? To keep your train of thought though, what would you do if we encounter a conduit that is different from the chosen one? Today, I am aware of 2 different implementations: TCG injects #UD [1] while KVM sets x0 to -1 [2]. IMHO the best way to resolve all of this mess is to consolidate to SMC as default PSCI handler and for now treat HVC as if it was an SMC call as well for virtual environments. Once we get nested virtualization, we will need to move to SMC as default anyway. Alex [1] https://git.qemu.org/?p=qemu.git;a=blob;f=target/arm/op_helper.c;hb=HEAD#l813 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/handle_exit.c#n52
