On Sat, Jul 13, 2019 at 05:53:57PM +0800, Guoheyi wrote: > Hi folks, > > Do it make sense to implement virtual SDEI in qemu? So that we can have the > standard way for guest to handle NMI watchdog, RAS events and something else > which involves SDEI in a physical ARM64 machine. > > My basic idea is like below: > > 1. Change a few lines of code in kvm to allow unhandled SMC invocations > (like SDEI) to be sent to qemu, with exit reason of KVM_EXIT_HYPERCALL, so > we don't need to add new API. So long as KVM_EXIT_HYPERCALL reports sufficient information so that userspace can identify the cause as an SMC and retrieve the SMC immediate field, this seems feasible. For its own SMCCC APIs, KVM exclusively uses HVC, so rerouting SMC to userspace shouldn't conflict. This bouncing of SMCs to userspace would need to be opt-in, otherwise old userspace would see exits that it doesn't know what to do with. > 2. qemu handles supported SDEI calls just as the spec says for what a > hypervisor should do for a guest OS. > > 3. For interrupts bound to hypervisor, qemu should stop injecting the IRQ to > guest through KVM, but jump to the registered event handler directly, > including context saving and restoring. Some interrupts like virtual timer > are handled by kvm directly, so we may refuse to bind such interrupts to > SDEI events. Something like that. Interactions between SDEI and PSCI would need some thought: for example, after PSCI_CPU_ON, the newly online cpu needs to have SDEs masked. One option (suggested to me by James Morse) would be to allow userspace to disable in the in-kernel PSCI implementation and provide its own PSCI to the guest via SMC -- in which case userspace that wants to implement SDEI would have to implement PSCI as well. There may be reasons why this wouldn't work ... I haven't thought about it in depth. Cheers ---Dave _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
