2017-07-11 1:08 GMT+08:00 Radim Krčmář <rkrcmar@xxxxxxxxxx>: > 2017-07-04 12:24+0800, Wanpeng Li: >> I observed that the hang during the boot of guest since pvspinlock >> depends on trapping the halt as mentioned in this patch: >> http://lkml.iu.edu/hypermail/linux/kernel/1202.0/03309.html，the hang >> disappears when I remove the KVM_FEATURE_PV_UNHALT CPUID flag in order >> to disable the pvspinlock in guest from kvm. So if disable the >> pvspinlock in the low latency scenario(idle=poll in guest) w/ vCPU and >> pCPU 1:1 pin can be acceptable? > > I think the hang happened because one VCPU did a halt with disabled > interrupts and then ignored KVM_HC_KICK_CPU from another VCPU. > The target VCPU does a VM exit, so handling the PV unhalt should be a > simple setting of GUEST_ACTIVITY_ACTIVE upon arch.pv.pv_unhalted. > > If it turns out to be complicated, then forbidding the userspace to > configure both is acceptable, (like you said, it currently doesn't make > much sense to combine them) kvm_spinlock_init() just check KVM_FEATURE_PV_UNHALT once to determine whether to enable pvspinlock, however, there is no easy way to check per-VM halt-exiting flag in the function __do_cpuid_ent(). Regards, Wanpeng Li
