2017-07-11 18:41+0800, Wanpeng Li: > 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(). Right, but we do not need to eliminate the flag from __do_cpuid_ent(). The documentation could say that if you enable per-VM halt-exiting, then you cannot set KVM_FEATURE_PV_UNHALT for VCPUs in that VM. And KVM can check when userspace sets the CPUID. (And at least forbid enablement of halt-exiting if there already are created VCPUs.) It's nothing pretty, so I hope that supporting the combination will work. :)
