On Tue, 28 May 2019 at 13:16, Tao Xu <tao3.xu@xxxxxxxxx> wrote: > > > On 27/05/2019 18:30, Peter Zijlstra wrote: > > On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote: > >> This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions > >> in kvm, and by default dont't expose it to kvm and provide a capability > >> to enable it. > > > > I'm thinking this should be conditional on the guest being a 1:1 guest, > > and I also seem to remember we have bits for that already -- they were > > used to disable paravirt spinlocks for example. > > > > Hi Peter, > > I am wondering if "1:1 guest" means different guests in the same host > should have different settings on user wait instructions? > > User wait instructions(UMONITOR, UMWAIT and TPAUSE) can use in guest > only when the VMCS Secondary Processor-Based VM-Execution Control bit 26 > is 1, otherwise any execution of TPAUSE, UMONITOR, or UMWAIT causes a #UD. > > So with a capability to enable it, we use qemu kvm_vm_ioctl_enable_cap() > to enable it. The qemu link is blew: > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05810.html > > By using different QEMU parameters, different guests in the same host > would have different features with or without user wait instructions. > > About "disable paravirt spinlocks" case, I am wondering if it uses Please refer to a4429e53c9 (KVM: Introduce paravirtualization hints and KVM_HINTS_DEDICATED) and b2798ba0b87 (KVM: X86: Choose qspinlock when dedicated physical CPUs are available). > kernel parameters? If it uses kernel parameters, different guests in the > same host may have same settings on user wait instructions. > > Or when we uses kernel parameters to disable user wait instructions, for > a host chooses to enable user wait instructions, we should do some work > on QEMU to choose disable or enable user wait instructions? > > Thanks > > Tao
