Re: [Question] About the behavior of HLT in VMX guest mode

["Radim Krčmář" <rkrcmar@redhat.com>]

2017-07-11 18:41+0800, Wanpeng Li:
> 2017-07-11 1:08 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> > 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. :)