Excerpts from Cédric Le Goater's message of June 26, 2020 5:17 pm: > Adding David, > > On 6/25/20 3:11 AM, Michael Ellerman wrote: >> Nicholas Piggin <npig...@gmail.com> writes: >>> KVM supports msgsndp in guests by trapping and emulating the >>> instruction, so it was decided to always use XIVE for IPIs if it is >>> available. However on PowerVM systems, msgsndp can be used and gives >>> better performance. On large systems, high XIVE interrupt rates can >>> have sub-linear scaling, and using msgsndp can reduce the load on >>> the interrupt controller. >>> >>> So switch to using core local doorbells even if XIVE is available. >>> This reduces performance for KVM guests with an SMT topology by >>> about 50% for ping-pong context switching between SMT vCPUs. >> >> You have to take explicit steps to configure KVM in that way with qemu. >> eg. "qemu .. -smp 8" will give you 8 SMT1 CPUs by default. >> >>> An option vector (or dt-cpu-ftrs) could be defined to disable msgsndp >>> to get KVM performance back. > > An option vector would require a PAPR change. Unless the architecture > reserves some bits for the implementation, but I don't think so. Same > for CAS. > >> Qemu/KVM populates /proc/device-tree/hypervisor, so we *could* look at >> that. Though adding PowerVM/KVM specific hacks is obviously a very >> slippery slope. > > QEMU could advertise a property "emulated-msgsndp", or something similar, > which would be interpreted by Linux as a CPU feature and taken into account > when doing the IPIs.
What I'm going to do is detect KVM here (we already have a KVM detection test using that dt property). The IPI setup code already has KVM hacks in it, so I don't really see the problem with puting them behind a KVM test. I think doing cpu ftrs or some specific entry for msgsndp in particular is the right way to go, but in the interests of making existing KVM work I'll do this. Thanks, Nick
