On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote: > 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. Be _very_ careful here! In systems without EL3 (and without NV), SMC UNDEFs rather than trapping to EL2. Given that, we shouldn't build a hypervisor ABI that depends on SMC. I am strongly of the opinion that (for !NV) we should always use HVC here and have KVM appropriately forward calls to userspace, rather than trying to use HVC/SMC to distinguish handled-by-kernel and handled-by-userspace events. For NV, the first guest hypervisor would use SMC to talk to KVM, all else being the same. > 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. I think this would be the best approach, since it puts userspace in charge of everything. However, this interacts poorly with FW-based mitigations that we implement in hyp. I suspect we'd probably need a mechanism to delegate that responsibility back to the kernel, and figure out if that has any interaction with thigns that got punted to userspace... Thanks, Mark. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
