On 28/05/2019 14:11, Wanpeng Li wrote:
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)
Hi Wanpeng,
Thank you! This information really helped me. After I read the code in
KVM/QEMU, I was wondering that with qemu command-line "-cpu
host,+kvm-hint-dedicated", then in KVM,
"kvm_hint_has_feature(KVM_HINTS_DEDICATED)" will be true, am I right?
Tao
